5 ms·

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

by __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?

by __jal 10y ago

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?