Hacker News Reader

The article mentioned ctags, which actually gets you quite far in this regard. Combined with CtrlP (a vim plugin) and the Silver Searcher, I navigate large codebases quite quickly. I do agree that full blown IDEs probably have better support for refactoring code, but so far the advantages of using vim/tmux/unix commands are much more valuable to me:

- it's more natural for me to have a shell as a starting point and jump into an editor, rather than the other way around; it suits my workflow much better

- I can combine tools in a very convenient way, `:!ls /tmp` real quick from my vim, fuzzy search some json file hidden inside an atrocious directory structure, `:!git status -s` to see what I've changed, and so on

- IDEs are often language specific, which implies learning a new IDE for every language; I only need to know vim, which I use for every language I use but Java

- I'm more of a keyboard person rather than a mouse person, so terminal based tools that have intuitive keyboard bindings suit me better than IDEs which often require you to learn some really awkward key combinations to do things that I do very quickly in vim; just take a look at the cheatsheets for e.g. PyCharm/IntelliJ and you'll see what I mean (yes I know about the vim plugin for IntelliJ, but as an experienced vim user, it's not that great)

I agree with your about language specific IDE's however the exceptions are sometimes very good.

I use intellij, it has intelligent support for Python, JavaScript (including node), SQL, HTML, CSS and PHP all working out the box with very little setup required, its the sheer integration of things.

I'm aware I could get close with emacs (except frankly its web modes suck) but I'd have to find all those bits myself, integrate them and hope that it wasn't fragile (you know updated fizz which was a dependency of too but bar uses a different version) and at the end I'd still have what I would regard as an inferior less cohesive tool.

There are no absolutes in matters of taste and that's what it is I think.

"I only need to know vim, which I use for every language I use but Java"

Java does seem to be the big exception in that 1) it's so overly verbose it almost requires an IDE to handle all of the boilerplate, 2) has enough static typing to allow deterministic refactoring, 3) is popular enough to support massive IDE engineering efforts.

I use IntelliJ for Java (and sometimes Scala), and Emacs for pretty much everything else.

vim-cscope gives the vim user everything the OP thinks he needs ..

There is nothing about text streams that prohibit tools from understanding whatever language you're writing in. Unless you have an very interesting compiler, your IDE is processing text, too.

But also, you seem to believe that somehow communication between applications is somehow limited to pipes, which makes the comparison inapt.

Ignoring the category error (text format in a data file vs. server application + storage), please explain what your IDE does that cannot be communicated over a socket? Or dbus (oh god please don't, but the point stands)?

I am not the parent you reply to, but see my previous reply for the capabilities you miss in 'dumb' editors.

"here is nothing about a text streams that prohibit tools from understanding whatever language you're writing in"

Well it might be true that you can deduce the language of some text stream but you need to make a big step in order to interpret it. You are talking about a compiler. Well a compiler takes a compilation unit, not some stream of text. To infer the semantics of a program the program needs to be present, not a part of it. Granted, a program might be broken up in independent modules, of course.

Make no mistake, a 'dumb' editor like sublimetext could understand a php symfony or a java struts project, if it would get the same analysis tools available in eclipse for example. It could be done, but it is massively more difficult than just running a syntax highlighter and running a rough tagger on some text. Its sad because I believe that fast, slim, editors that know as much as a massive IDE is the best of both worlds.

I have seen the code for eclipse -- there is so much dancing, it's a miracle that handling a key press eventually completes in some time.

> I have seen the code for eclipse -- there is so much dancing, it's a miracle that handling a key press eventually completes in some time.

In many IDE's it barely does, I've had issues with Eclipse, Visual Studio and IntelliJ at some point regarding input latency or the total freeze of the UI while it tries to handle magic with my input in the background.

Visual Studio has gotten progressively better since VS2010, especially with Roslyn; IntelliJ-based products have made strides since IDEA 13 where they really started to focus on input latency; Eclipse was never quite as bad, but it's a pain to use compared to VS or IntelliJ so it's irrelevant that it freezes 10% less in my eyes.

Text editors do have this though, YouCompleteMe for instance does semantic analysis on several languages to generate its completions (using different backends, like Clang or Jedi). Some of the Haskell plugins for Vim and Emacs are also downright amazing with the sort of code analysis and even code derivation they can do right in the editor.

"Make no mistake, a 'dumb' editor like sublimetext could understand a php symfony or a java struts project, if it would get the same analysis tools available in eclipse for example."

And at that point, it would be an IDE.

It's not about what UNIX can theoretically do. Yeah, sure, you can refactor a method over a socket, I guess, just as you could use VBA macros in Excel to write a Tetris game using spreadsheet cells as block.

The question is whether there is actually good refactoring support on the UNIX command line that can compete directly with the likes of ReSharper or IntelliJ IDEA? I haven't seen anything coming close to that yet.

The fact is, there are actually a few implementations of Tetris and Breakout for Excel, and probably a few command line refactoring tools here and there. But just as no one is going to play a clunky Tetris game in Excel just for the novelty of it, I don't see myself using an inconvenient and limited command-line refactoring tool.

> The question is whether there is actually good refactoring support on the UNIX command line that can compete directly with the likes of ReSharper or IntelliJ IDEA? I haven't seen anything coming close to that yet.

There's nothing stopping people from making it. IDEA Community is open source; I haven't looked at the code but I trust it can be decoupled and made into a separate utility.

If you want an example that's out there, Go has support for refactoring via tools like eg and gorename, and you can use them in an IDE, in a text editor or in a terminal with nothing more than GNU coreutils.

Then people can just go ahead make it, instead of complaining about lazy developers locking themselves into Jetbrains tools or eclipse or trying to do everything from within Emacs or Vim.

Right now you've got very basic refactoring tools for Go and JRefactor. Maybe a few other tools I don't know.

But in that case I don't see what's the point of running this tool from the CLI instead of configuring VIM/Emacs/{insert your favourite IDE or Editor} to run it on the function under your cursor with just a few keystrokes.

This is the equivalent of arguing that there are no differences between two languages because they're both Turing complete.

I don't see where they were saying there's no difference.

> There is nothing about text streams that prohibit tools from understanding whatever language you're writing in. Unless you have an very interesting compiler, your IDE is processing text, too.

Well, the text stream lacks context of related entities. Let's say you're piping a single source file. The program you're piping to can certainly parse "import foobar", but how will it know what's in "foobar"? You could argue that it could parse foobar, but then it would need to recursively parse all of "foobar"'s dependencies too, and so on, which seems pretty inefficient if you're doing that a lot compared to a program keeping it in memory. Sure you could create files to cache that data, but at that point you're sort of waltzing into IDE territory anyway.

Besides, the "unix as an IDE" idea is based on using general purpose utilities, not specialized language specific ones, and those utilities make no strong assumptions about the input text.

>The program you're piping to can certainly parse "import foobar", but how will it know what's in "foobar"?

That's the "understanding which language you're in" part comes in.

> You could argue that it could parse foobar, but then it would need to recursively parse all of "foobar"'s dependencies too, and so on, which seems pretty inefficient if you're doing that a lot compared to a program keeping it in memory. Sure you could create files to cache that data, but at that point you're sort of waltzing into IDE territory anyway.

The whole point is that "Unix is your IDE". If a specialized tool benefits from caching, it can use it. If more than one tool can share the cache, pass it as a parameter or pipe it in. If it speaks in a universal language (ideally, simple text) and it's a specialized tool, it's certainly following the Unix way.

> Besides, the "unix as an IDE" idea is based on using general purpose utilities, not specialized language specific ones, and those utilities make no strong assumptions about the input text.

That's another arbitrary line. It makes sense that awk or grep work with any type of text. It doesn't make sense that gcc or a tool like I just explained "makes no strong assumptions" about what's coming in.

> That's the "understanding which language you're in" part comes in.

... which standard unix utilities can't do. grep and awk can't reliably determine if a symbol is in a comment, and I can't tell it "rename symbol Foo, but only if it's used as a type identifier in my project".

The question isn't if unix could theoretically work as well as an IDE if you added a few thousand custom userland programs that understood language context. The question is if unix, out of the box right now, is competitive with a high end IDE. It's not, because it can't possibly understand your code.

Whether you like IDE's or not, the entire point of an IDE is that it's more than a dumb text editor because it understand what you're typing into it. If all your IDE offers is text editing functionality unix can do, then it's a bad IDE.

> The question isn't if unix could theoretically work as well as an IDE if you added a few thousand custom userland programs that understood language context. The question is if unix, out of the box right now, is competitive with a high end IDE. It's not, because it can't possibly understand your code.

You need to download tools for your language just like you downloaded an IDE. The whole point of Unix is that you have specialized, composable tools for your purpose. Don't move the goalposts.

Which tools do you know that will handle automatic refactoring in, say, java, from the command line? Genuinely curious, I've wanted something for this

gofmt is an example of a tool for refactoring on the command line.

There isn't much demand for a similar tool for Java, but I have no doubt that a few months of effort could build one out of Eclipse. Its startup time probably wouldn't be great though. We already have eclim, that treats Eclipse as a daemon serving refactoring APIs to clients, to mitigate the configuration and startup problems.

"There isn't much demand for a similar tool for Java..."

What empirical evidence do you have for this?

At one point I looked very hard for good Java tools for Unix and/or Emacs, and found nothing. I imagine many others have done similar investigations and came up empty.

So I think its an open question whether Java refactoring tools for Unix don't exist because there is no demand, or whether there are engineering and productivity reasons why such tools work better as part of an IDE.

(I will say, though, the existence of similar command line tools for Go indicate similar tools might be possible for Java, also. Or maybe this is just due to Go being designed to be easy to parse?)

The reason there isn't demand is because the same tool for Java would necessarily be a lot slower on startup. The version of the tool that eliminates the slowdown by daemonizing does exist: it's called eclim.

Personally I sometimes use eclimd in Eclipse from emacs. But it's a bit flakey. Usually I switch between an IDE and emacs depending on whether the current task is text-intensive or not.

IMO the entire language-specific modes thing in emacs is a collection of hacks (eg.: using regexes for highlighting! highlighting as a characteristic of the text!) and woefully under-architected; this is a much bigger problem than lack of any language-specific tool. Until elisp is replaced with a faster language with less dynamic scope by default (Scheme would be fine), I don't really see it improving.

Of course there's nothing text stream cannot do. Because, at the very worst, you can always feed the text stream to parser to convert it to structured object.

But I don't want to do the gluing. I want to refactor code, not to teach the tool how o understand the code.

Why do you need text editor when everything are just bytes?

> The difference is IDEs understand the underlying structure of the code, including relationships between entities, symbol types in their context, indexes for searching, and so on.

This is only true because purpose-built IDEs embed the tooling to do so, but nothing prevents said tooling to be extracted, to be used in any way fit by any editor or non-editor tool. Case in point: gocode/gorename, C#'s Roslyn project.

> And unix can never be a very good IDE, comparatively, because "text streams" are not a sufficiently good data structure for representing program structure.

The article is not about Unix as pipes of streamed data (which BTW can very well be binary) but Unix as individual tools that compose into a greater whole.

This a 1000 times. Text is beautiful but if your editor doesn't understand it, you are, quite paradoxally, limited in your editing of it. Think refactoring, think auto-completion. There is a difference between making type-correct suggestions and saying "foo? oh, what about foobar, i saw it mentioned somewhere?!"

I often even use auto-completion in eclipse to get the hang of a library and explore its capabilities.

Code in an IDE is just a text editor with the aforementioned tools built in. Such tools are available for the terminal as well - both command line based and as vi or emacs plugins.

Saying UNIX is like an CSV compared to a relational database is, frankly, a hugely ignorant comment. The real differences between UNIX and an IDE is that the tools available in an IDE are discoverable where as UNIX requires a little more research and self assembly.

I frequently flitter between using a GUI IDE and just working entirely in the terminal - depending on my mood. Generally I find the terminal to be more productive, albeit I've have 30 years of experience in command line environments so I'm very much at home in a terminal. However the one thing I do find quicker in a GUI IDE is switching between different functions on different source files. Not that it's slow in the command line either, but that's the biggest inconvenience I have. So these days I generally use a GUI text editor for reading and writing the code and the command line for code refactoring, compiling, debugging, etc. It's a ratio that seems to work well for me.

There really needs to be a standard interface that all compiler toolchains can deal with for emitting program structure. All implementations deal with this problem their own way.

For C# there is OmniSharp based on NRefactory, and also Microsoft's Roslyn. For C++ there are tools based on libclang. Rust has Racer. It would be nice if there were an interface an editor could implement which gave access to all of these languages.

Tada https://github.com/Microsoft/language-server-protocol

Wasn't Steven Yegge working on something like this for Google?

A toolchain to handle any/most languages?

> And unix can never be a very good IDE, comparatively, because "text streams" are not a sufficiently good data structure for representing program structure.

This is a simplistic view of the system; you essentially have binary over streams and can use it to encode in any format you wish.