7 ms·

The difference is IDEs understand the underlying structure of the code, including relationships between entities, symbol types in their context, indexes for sea

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. That allows you to express transforms that can't be expressed if everything is just a text stream. I can grab a chunk of a function in resharper and do an "extract method", and it can figure out data dependencies, or I can do a "find usages" for a variable called "map" and not pick up every comment that has the word "map" in it, or I can move a class to a new module and let it figure out all the call sites that need to change their using statements. Comparing unix to an IDE is like comparing a CSV file to a relational database. They both store data in tables, but you're not going to replace Postgres with grep, I hope, even though you could do very basic "queries" with grep. And unix can never be a very good IDE, comparatively, because "text streams" are not a sufficiently good data structure for representing program structure.

__jal 10y ago
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)?
- exceptione 10y ago
  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.
  - snuxoll 10y ago
    > 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.
  - gh02t 10y ago
    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.
  - jimbokun 10y ago
    "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.
- unscaled 10y ago
  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.
  - mixedCase 10y ago
    > 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.
    - unscaled 10y ago
      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.
- solipsism 10y ago
  This is the equivalent of arguing that there are no differences between two languages because they're both Turing complete.
  - Volt 10y ago
    I don't see where they were saying there's no difference.
- overgard 10y ago
  > 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.
  - mixedCase 10y ago
    >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.
    - overgard 10y ago
      > 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.
- joesb 10y ago
  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?
exceptione 10y ago
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.
snarfy 10y ago
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.
- icholy 10y ago
  Tada https://github.com/Microsoft/language-server-protocol https://github.com/Microsoft/language-server-protocol
  - emmelaich 10y ago
    Wasn't Steven Yegge working on something like this for Google? A toolchain to handle any/most languages?
- deleted 10y ago
  [deleted]
beefsack 10y ago
> 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.
objectified 10y ago
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)
- noir_lord 10y ago
  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.
- jimbokun 10y ago
  "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.
lloeki 10y ago
> 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.
laumars 10y ago
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.

__jal 10y ago

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)?

exceptione 10y ago
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.
- snuxoll 10y ago
  > 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.
- gh02t 10y ago
  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.
- jimbokun 10y ago
  "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.
unscaled 10y ago
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.
- mixedCase 10y ago
  > 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.
  - unscaled 10y ago
    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.
solipsism 10y ago
This is the equivalent of arguing that there are no differences between two languages because they're both Turing complete.
- Volt 10y ago
  I don't see where they were saying there's no difference.
overgard 10y ago
> 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.
- mixedCase 10y ago
  >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.
  - overgard 10y ago
    > 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.
joesb 10y ago
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?

exceptione 10y ago

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.

snarfy 10y ago

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.

icholy 10y ago
Tada https://github.com/Microsoft/language-server-protocol https://github.com/Microsoft/language-server-protocol
- emmelaich 10y ago
  Wasn't Steven Yegge working on something like this for Google? A toolchain to handle any/most languages?
deleted 10y ago
[deleted]

beefsack 10y ago

> 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.

objectified 10y ago

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)

noir_lord 10y ago
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.
jimbokun 10y ago
"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.

lloeki 10y ago

> 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.

laumars 10y ago

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.