Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unix as IDE

sanctum.geek.nz

Post reply on HN
Print view View original

101–110 of 214 posts

Re: Unix as IDE

#101

Post by unscaled »

__jal wrote: post #92
overgard wrote: post #83

Earlier quoted context omitted.

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"…

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 + storag…

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.

Re: Unix as IDE

#102

Post by solipsism »

__jal wrote: post #92
overgard wrote: post #83

Earlier quoted context omitted.

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"…

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 + storag…

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

Re: Unix as IDE

#103

Post by overgard »

__jal wrote: post #92
overgard wrote: post #83

Earlier quoted context omitted.

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"…

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 + storag…

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

Re: Unix as IDE

#104

Post by snuxoll »

exceptione wrote: post #99
__jal wrote: post #92

Earlier quoted context omitted.

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 + storag…

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 compil…

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

Re: Unix as IDE

#105

Post by overgard »

amelius wrote: post #34
the8472 wrote: post #33

It lacks the I in IDE. Those different tools are not integrated. In a java IDE the debugger steps through your source in the same editor view that you just used for editing. You can hover over each identifier while you code or debug to get the docs in a floating panel. Editing incrementally computes compilation errors while you type. Content assist has complete knowledge of the types at your caret position and thus c…

If you can't debug with just print statements, you're doing it wrong :)

Just because a thing is sufficient doesn't make it efficient or pleasant.

Re: Unix as IDE

#107

Post by mixedCase »

overgard wrote: post #103
__jal wrote: post #92

Earlier quoted context omitted.

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 + storag…

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

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

Re: Unix as IDE

#108

Post by mixedCase »

unscaled wrote: post #101
__jal wrote: post #92

Earlier quoted context omitted.

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 + storag…

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

Re: Unix as IDE

#109

Post by Koshkin »

blakeyrat wrote: post #87
beachstartup wrote: post #81

Earlier quoted context omitted.

> Yet proposing a better, widely useful and backwards compatible alternative is extremely hard. we keep inventing new stuff, but always end up just using it to emulate and display terminals in new and interesting ways. even my new, shiny 4G LTE + iOS + touchscreen mobile device is used to run a terminal emulator over ssh half the time. i've even use its web browser to run a web RDP session .. to display a terminal co…

Only certain types of information. It's not a great way to display, for example, a comparison between two similarly-edited movie trailers. Or a map of Bremen. Or the annotations on your 2016 second quarter financial sum-up spreadsheet. The big problem with the entire Unix philosophy is that it assumes all important data is text, when in the real world very little of it is. If you're one of the few people who can get…

> it assumes

True, UNIX was designed, in part, to make the processing of textual data as easy as possible. It was never intended to be running inside a photo camera or a drawing pad.

On the other hand, from the very beginning UNIX was just as capable of processing binary data as well as controlling various devices, such as typesetters and graphical displays as any other reasonably powerful OS of the time.

Post reply on HN