4 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,

> 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.
  - mixedCase 10y ago
    > 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.
    - paulfurtado 10y ago
      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
      - barrkel 10y ago
        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.

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.
- mixedCase 10y ago
  > 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.
  - paulfurtado 10y ago
    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
    - barrkel 10y ago
      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.