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

171–180 of 214 posts

Re: Unix as IDE

#171

Post by fit2rule »

objectified wrote: post #141
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"…

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

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

Re: Unix as IDE

#172

Post by beachstartup »

justinlardinois wrote: post #128
beachstartup wrote: post #95

Earlier quoted context omitted.

you've probably never: 1. been forced to use a system with nothing but vi, ed, and ex, which was common for commercial unixes until the 90's 2. had to make thousands of edits to thousands of files in minutes without access to a scripting environment or other more advanced tools 3. had to edit and debug a program under the above conditions on a super laggy dialup internet connection vi is a force multiplier for operat…

To be honest vi and vim are different enough that as someone who was taught on vim, I get lost when I have to do anything beyond opening a file in vi.

yeah, it's pretty awful.

Re: Unix as IDE

#173

Post by jimbokun »

mixedCase wrote: post #114
blakeyrat wrote: post #96

Earlier quoted context omitted.

Git was made in, what, 2005. We knew about discoverability then. We knew about accessibility then. We knew about user testing, about UX. Git makes use of zero of those concepts. In fact, it seems to be actively hostile towards its users^. We also had source control packages that were not only easier to use, but had more features: TFS let you put a lock on files that don't merge well, for example. Both TFS and Subvers…

> Yes, someone's going to come in here and say, "well it's a professional tool for professionals therefore it's ok that it's difficult to use and hostile and not accessibility to people who can't use a CLI due to physical limitations because it's a professional tool for professionals. Oh that's nonsense. First of all, because git is a CLI application you can easily build a GUI for it, and there are a lot of them for…

"Second, what "physical limitations" put people into a position where they can code but they can't use a CLI?"

It's not the lack of a GUI, it's that the CLI interface is very poorly designed.

Re: Unix as IDE

#174

Post by catnaroek »

qwertyuiop924 wrote: post #158
catnaroek wrote: post #120

Earlier quoted context omitted.

To spare, you say? I want to use that computing power for my own purposes. I suddenly decided I want to multiply gigantic matrices.

Okay. Go write some C, or some Asm. It might feel unpleasant to you, but if you use most other langauges, you'll be wasting too many cycles, and you won't be using that computing power for your own puposes. Don't forget to use as few abstractions as possible, and remember: every function call takes valuable time and computation.

> Don't forget to use as few abstractions as possible

Huh? I'm perfectly fine with abstractions. Just not with abstractions that are suboptimally designed and implemented.

> Don't forget to use as few abstractions as possible

Maybe you're confusing abstraction with runtime dispatch?

> every function call takes valuable time and computation.

Stroustrup's (whom otherwise I don't regard as a great language designer) principle applies: abstractions must elaborate to the best possibly code you would've manually written.

Re: Unix as IDE

#175

Post by catnaroek »

qwertyuiop924 wrote: post #157
catnaroek wrote: post #119

Earlier quoted context omitted.

Checking alone isn't the point. As things stand, it's no better than C, where the type checker can approve your code, yet it still has undefined behavior.

So you want exhaustive matching? I don't know if any lisp provides that by default. One of them probably does, somewhere. But since you don't mind Lisp syntax, and really like type systems, have you tried Shen? ( http://www.shenlanguage.org ) it's an interesting project.

> But since you don't mind Lisp syntax, and really like type systems, have you tried Shen?

I also want:

(0) Type inference. Shen seems to require all typed code to be manually type-annotated.

(1) A decent module system. There seems to be no mention of abstract types in Shen's documentation.

(2) A guarantee that dynamically typed code won't break abstractions defined in statically typed code.

Re: Unix as IDE

#176

Post by qwertyuiop924 »

catnaroek wrote: post #175
qwertyuiop924 wrote: post #157

Earlier quoted context omitted.

So you want exhaustive matching? I don't know if any lisp provides that by default. One of them probably does, somewhere. But since you don't mind Lisp syntax, and really like type systems, have you tried Shen? ( http://www.shenlanguage.org ) it's an interesting project.

> But since you don't mind Lisp syntax, and really like type systems, have you tried Shen? I also want: (0) Type inference. Shen seems to require all typed code to be manually type-annotated. (1) A decent module system. There seems to be no mention of abstract types in Shen's documentation. (2) A guarantee that dynamically typed code won't break abstractions defined in statically typed code.

I'm pretty sure shen has limited type inference. There might be ADTs.

Re: Unix as IDE

#177

Post by qwertyuiop924 »

catnaroek wrote: post #174
qwertyuiop924 wrote: post #158

Earlier quoted context omitted.

Okay. Go write some C, or some Asm. It might feel unpleasant to you, but if you use most other langauges, you'll be wasting too many cycles, and you won't be using that computing power for your own puposes. Don't forget to use as few abstractions as possible, and remember: every function call takes valuable time and computation.

> Don't forget to use as few abstractions as possible Huh? I'm perfectly fine with abstractions. Just not with abstractions that are suboptimally designed and implemented. > Don't forget to use as few abstractions as possible Maybe you're confusing abstraction with runtime dispatch? > every function call takes valuable time and computation. Stroustrup's (whom otherwise I don't regard as a great language designer) pri…

Every abstraction has a cost somewhere. If you want to use your computer to its full potential, avoid them all.

Re: Unix as IDE

#178

Post by mixedCase »

qwertyuiop924 wrote: post #159
mixedCase wrote: post #115

Earlier quoted context omitted.

> And I need to edit over SSH a lot. Try sshfs :) Surprising that someone who has tried Plan 9 hasn't come to love specialized filesystems!

I would, but in the locations I'm in, the only computer I can access is my school chromebook: no X. :-(

sshfs doesn't require X...? It's just a filesystem.

Re: Unix as IDE

#179

Post by qwertyuiop924 »

mixedCase wrote: post #178
qwertyuiop924 wrote: post #159

Earlier quoted context omitted.

I would, but in the locations I'm in, the only computer I can access is my school chromebook: no X. :-(

sshfs doesn't require X...? It's just a filesystem.

No, but Acme/Sam ports do. And emacs, vim, and sam and acme ports all require a POSIX api which the chromebook lacks.

Re: Unix as IDE

#180

Post by barrkel »

jimbokun wrote: post #169
barrkel wrote: post #140

Earlier quoted context omitted.

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…

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.

Post reply on HN