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

91–100 of 214 posts

Re: Unix as IDE

#91

Post by beachstartup »

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…

this is HN, so i was talking only about systems admin and nuts-and-bolts development, but i would also argue that in all of your examples, having a terminal in addition to the other display formats would help convey more information as well as offer a better command interface. a good example would be autocad which has the drawing window but also a powerful terminal (i believe it was lisp-based) that you used in parallel.

Re: Unix as IDE

#92

Post by __jal »

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

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

Re: Unix as IDE

#93

Post by joemi »

faho wrote: post #55
joelthelion wrote: post #39

Earlier quoted context omitted.

> The problem is that this is a whole lot of cargo cult. It does have the efficient parts, but it also has a lot of accumulated cruft, archaic limitations, arbitrariness, and plain bad decisions. I don't think the problem is cargo culting. Replacing things with better solutions is hard. Take the venerable ANSI terminal. It's archaic and cryptic, I think most people would agree on that. Yet proposing a better, widely…

>I don't think the problem is cargo culting. Replacing things with better solutions is hard. Take the venerable ANSI terminal. It's archaic and cryptic, I think most people would agree on that. Yet proposing a better, widely useful and backwards compatible alternative is extremely hard. Which is why no one has succeeded yet. Making a better alternative isn't hard. Getting everyone to use it is.

I forget where I read this, but someone once talked about how a new standard can't just be "better". Instead it has to be _a lot_ better and probably even bring a lot of really good new stuff to the table, otherwise not enough people will bother switching to it.

Re: Unix as IDE

#94

Post by exceptione »

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

This a 1000 times. Text is beautiful but if your editor doesn't understand it, you are, quite paradoxally, limited in your editing of it. Think refactoring, think auto-completion. There is a difference between making type-correct suggestions and saying "foo? oh, what about foobar, i saw it mentioned somewhere?!"

I often even use auto-completion in eclipse to get the hang of a library and explore its capabilities.

Re: Unix as IDE

#95

Post by beachstartup »

cdevs wrote: post #51

I've tried for the past couple of years to get into vim but I can't force myself to remember the odd short cuts I can't seem to ever match up with the action it's doing. I could if I rewrote them butttttt then that blows when I want to jump into a new server without my config. So it's always been nano for one liners and sublime through sftp mounted filesystem.

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 operating a terminal under duress in adverse network conditions. that's literally why it was developed. i say it does an even better job of it under good, modern conditions and unless you look at it through that lens, it's never going to make much sense to you. and those adverse conditions still pop up now and then, especially with wireless networks and public cloud shitstorms.

"[Bill] Joy explained that the terse, single character commands and the ability to type ahead of the display were a result of the slow 300 baud modem he used when developing the software and that he wanted to be productive when the screen was painting slower than he could think."

https://en.wikipedia.org/wiki/Vi

Re: Unix as IDE

#96

Post by blakeyrat »

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.

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 Subversion allowed you to check-out only small portions of the repository.

Git has some nice things. It's generally fast, for example. It allows developers to work offline. But when the developer community apparently unilaterally chose to adopt it, we threw away a lot of good stuff, let's not forget that.

I'd also question that Git is "universally respected". I've worked with a great many programmers who found it just as unpleasant and unfriendly as I do. The reason people use Git is because other developers demand it as a condition of employment, not because it's enjoyable. In that respect, it's in the same class of application as, say, OracleApps or Lotus Notes.

---

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

Well.

Sony Vegas is a professional tool for professionals, and somehow it doesn't have even remotely the amount of usability problems Git does. So is Adobe Photoshop. So I don't buy that argument.

Re: Unix as IDE

#97

Post by __jal »

carterehsmith wrote: post #90
__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…

> vi + shell + standard utilities + what I build That is good. Can you tell us, what exactly did you build with "vi + shell + standard utilities + what I build"

Mostly systems tools for managing operations in companies with complex internet presences.

Re: Unix as IDE

#98

Post by bigger_cheese »

qwertyuiop924 wrote: post #84
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…

The I is Emacs. It adds a heapload of tools on top of what's already there, integrates what is already there, and is a frankly awesome enviroment. It has most of what you described, but it starts faster than an IDE, and is generally better: I don't think and IDE will be beating Paredit and Slime/Geiser, or JS2, or gdb-mode, any time soon. Not to mention, compared to most IDEs, Emacs is trivial to extend. You know tho…

I have a guilty confession to make. I don't know how to use Visual Studio. Which seems absurd because I am a heavy Emacs user. Last Time I tried to use Visual Studio (which was about six years ago) I found it kept getting in the way of what I was trying to do. It almost had too much complexity. I ended up throwing my hands in the air and 'saying forget this' I'm going back to what I know, which is Unix and Emacs. At this point I think I'm too entrenched in my habits to have the patience to give anything else a try. Maybe slavish adherence to my tools makes me a bad developer but if it isn't broken why replace it.

Re: Unix as IDE

#99

Post by exceptione »

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

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.

Re: Unix as IDE

#100

Post by lucb1e »

cdevs wrote: post #51

I've tried for the past couple of years to get into vim but I can't force myself to remember the odd short cuts I can't seem to ever match up with the action it's doing. I could if I rewrote them butttttt then that blows when I want to jump into a new server without my config. So it's always been nano for one liners and sublime through sftp mounted filesystem.

Note that Vim is pretty much identical to nano when you press the letter i. Then hit escape and use :wq to write to disk and quit. Over time you'll probably start using more and more Vim features to do text editing quicker.

It took me two years to learn Vim well enough that I could objectively say it works better than standard text editors. I'm not surprised you didn't succeed in learning it all at once. It's like using a mouse for the first time ever that comes with 50 buttons. I don't think anyone could learn that and put it to use from muscle memory (that's where it really starts to pay off) in one sitting.

Post reply on HN