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

141–150 of 214 posts

Re: Unix as IDE

#141

Post by objectified »

overgard wrote: post #83
__jal wrote: post #32

This was how Unix was presented to me when I was first introduced to me. I was told it was like industrial machinery - designed for those who know how to use it, efficient, dangerous if you aren't careful. Which is exactly what a good tool should be. When IDEs (the kind that comes as a GUI'ed bundle of things thought to be the most appropriate for the purpose by committee of someones, somewhere) started becoming popu…

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

Re: Unix as IDE

#142

Post by joesb »

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

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?

Re: Unix as IDE

#143

Post by lloeki »

overgard wrote: post #83
__jal wrote: post #32

This was how Unix was presented to me when I was first introduced to me. I was told it was like industrial machinery - designed for those who know how to use it, efficient, dangerous if you aren't careful. Which is exactly what a good tool should be. When IDEs (the kind that comes as a GUI'ed bundle of things thought to be the most appropriate for the purpose by committee of someones, somewhere) started becoming popu…

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

Re: Unix as IDE

#144

Post by joesb »

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…

> Multimedia artists are among the people who are most resistant to ever switch tools due to how much they have mentally invested into the complexities of their go-to application. Your example is far from good.

And here we are talking about people not wanting to use IDE because how much they have invested in their favorite work flow mental model.

Re: Unix as IDE

#145

Post by imtringued »

sdegutis wrote: post #42
TeMPOraL wrote: post #31

Earlier quoted context omitted.

It's a powerful lever, yes, but if we talk efficiency, then it very much sucks. You get a crappy pseudo-programming language (shell) that spawns a new process (!) for almost every function call, and communicates with unstructured text that has to be parsed and reparsed every step of the way. The only benefits of this system are that it's already there with batteries included, and that it became a de-facto standard.

Well also that it's entirely dynamic. You can create and edit "functions" on the fly, which will exist immediately, and are persisted across "sessions". But despite how convenient this is, there's basically no way to make it a whole lot more efficient. Especially the automatic "persisting" feature, there's no other way to do that than writing to disk. That said, you get a lot of similar behavior to this in things lik…

>but due to the nature of the underlying JVM, you still have to restart it every once in a while.

The DCEVM project almost removed any limitations on hotswapping code in the JVM until oracle hired the people behind it and then never integrated it into their JVM.

Re: Unix as IDE

#146

Post by TurboHaskal »

qwertyuiop924 wrote: post #48
Avshalom wrote: post #44

Earlier quoted context omitted.

This is of course such a transparently good idea that Acme and 9term adopted it too.

I was never as much a fan of Acme. It was a neat idea, but I don't think it was executed as well as Emacs was. And it doesn't work super well outside plan9. And I need to edit over SSH a lot. And keyboard > mouse, IMHO.

I use Acme on and off. I will never be as productive with it as I am with Emacs (I depend way too much on autocompletion, contextual text wrapping, org-mode and magit), but the philosophy appeals to me.

UNIX as an IDE never truly made sense until I discovered Acme. It was truly a zen-like experience.

Re: Unix as IDE

#147

Post by imtringued »

Unix as IDE is an oxymoron simply because it's not integrated. How about we swap the "I" with something else? Maybe Universal Development Environment?

Re: Unix as IDE

#148

Post by noir_lord »

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…

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.

Re: Unix as IDE

#149

Post by josteink »

blakeyrat wrote: post #96
haldean wrote: post #89

Earlier quoted context omitted.

If you're going to hate on something almost universally respected, you're going to have to explain yourself.

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…

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

I was with you all the way here, and then suddenly...

> We also had source control packages that were not only easier to use, but had more features: TFS let you

Suddenly you mention TFS as an example of something good. Mind blown.

TFS is absolutely among the worst "popular" version control systems I've worked with, and maintaining several branches and merging between them is pure hell.

In TFS a branch is something heavy which moves at tectonic speeds. Trying to maintaining agility in a world of TFS is just not viable.

> TFS let you put a lock on files that don't merge well, for example.

A "key" feature which more often than not is a source of problems you only have with TFS.

90% of the failed merges I've had with TFS has been because of its completely inadequate handling of binary files.

> Both TFS and Subversion allowed you to check-out only small portions of the repository.

This has nothing to do with Git specifically. This is a difference between centralized and distributed. If you want the benefits of distributed source-control, you'll have to pay the cost.

> I'd also question that Git is "universally respected".

Yes. Universally will obviously be easily disproven. I'd say "widely respected" instead.

Re: Unix as IDE

#150

Post by noir_lord »

haldean wrote: post #89
blakeyrat wrote: post #86

Earlier quoted context omitted.

Git is just repeating all the same mistakes all over again, just when it looked like things were starting to maybe get a bit better. I'm amazed you're citing that as a positive example.

If you're going to hate on something almost universally respected, you're going to have to explain yourself.

I'm a vote in the got sucks camp, its not universally respected amongst the programmers I know we just put up with it because its dominant.

I always preferred mercurial but that fight is largely lost, I could use a mercurial -> whatever bridge but I'd still need to know git for when things break.

Git's ui is simply horrible in my opinion.

Post reply on HN