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 popular, I didn't get it, at all. Put aside tool tips (which annoy me far more than is rational); it seemed to me that the idea was to build a toy model workshop on the work bench of a fully outfitted workshop. Why would anyone want to use that? Why bother in the first place?
I mean, I do get it. And who knows, maybe if I used one of those long enough to break muscle memory and the conceptual assumptions that don't map, I'd change my mind. But so far, vi + shell + standard utilities + what I build have served me just fine, and if for some reason I were to need "more power", whatever that means, I'd probably move to emacs.
And I still maintain that tool tips/balloon help/obscuring the very thing you're pointing at is a stupidly rude anti-pattern. Even worse is not making it possible to turn off.
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" for a variable called "map" and not pick up every comment that has the word "map" in it, or I can move a class to a new module and let it figure out all the call sites that need to change their using statements.
Comparing unix to an IDE is like comparing a CSV file to a relational database. They both store data in tables, but you're not going to replace Postgres with grep, I hope, even though you could do very basic "queries" with grep. And unix can never be a very good IDE, comparatively, because "text streams" are not a sufficiently good data structure for representing program structure.
>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.
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.
Hey, don't ask me. I'm an emacs user. I have a fully outfitted workbench on top of my workbench, specifically optimized for text editing, which can interface with the workbench beneath it, so you never have to leave.
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 can make accurate suggestions what can be inserted there. Saving the file while debugging automatically compiles the code, runs tests and splices it into the running VM so you can continue debugging the running process with the new code while also showing you which lines you changed relative to the most recent VCS commit. And of course there's more.
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 those really simple plugins that provide a tiny amount of incredibly useful functionality? Yeah, we have those, but most of them are so trivial to implement that they're just snippets you can copy into your config. Once you get the hang of elisp, you can be writing real, useful commands in a matter of minutes. Sure, not the big stuff, but still things that matter.
>But I think that trying to shoehorn Vim or Emacs into becoming something that it’s not isn’t quite thinking about the problem in the right way.
...Well, this is clearly a Vim user. If you're never leaving Emacs, and you're writing plugins to do everything inside it, you're using Emacs exactly as intended.
"It was all just text. Why did you need another application for it? Why should only the shell prompt be editable? Why can’t I move my cursor up a few lines to where the last command spewed out its results? All these problems simply disappear when your shell (or shells) simply becomes another Emacs buffer, upon which all of the text manipulation power of Emacs can be brought to bear."
At some point I realized Unix is basically a long-running IDE + REPL, and thought that was just so cool. And then I realized how horribly inefficient it is at being that. So I started longing for the days when we had some kind of OS where it actually is a IDE + REPL, like an OS based on Lisp. And then I learned that that already was done and didn't turn out as cool as people had hoped. Oh well.
The C64 was like that. Not Lisp but it booted right into a BASIC REPL. BASIC was the C64's operating system. I still think there is a niche for such a system today (mainly for developing rapidly changing business applications you'd nowadays use Excel for, as well as education).
This instantly brought to mind the classic 1984 book, The Unix Programming Environment, by Brian Kernighan and Rob Pike [1]. Note that they call Unix a programming environment, not an operating system. This book shows that the original purpose of Unix is to be a tool for writing software.
They're not calling Unix a programming environment instead of an operating system. The title of the book refers to the programming environment of the Unix operating system.
I recently contributed an awk filter for doing text transformation. I think it was some kind of code for converting POSIX attributes to LDIF or something like that. I was kind of surprised when one of the replies that I received was a request to re-implement it as a Python API. They didn't seem interested in using piplelines as a way to glue utilities together into something bigger. I don't have anything against Python, I just like the idea of being able to integrate wildly different implementations (C, perl, awk, sed, m4, Perl, Python, etc...) to solve problems. It's a kind of component based approach that the Unix/Linux/BSD shell makes really easy.
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.
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."
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.
[+] [-] __jal|9 years ago|reply
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 popular, I didn't get it, at all. Put aside tool tips (which annoy me far more than is rational); it seemed to me that the idea was to build a toy model workshop on the work bench of a fully outfitted workshop. Why would anyone want to use that? Why bother in the first place?
I mean, I do get it. And who knows, maybe if I used one of those long enough to break muscle memory and the conceptual assumptions that don't map, I'd change my mind. But so far, vi + shell + standard utilities + what I build have served me just fine, and if for some reason I were to need "more power", whatever that means, I'd probably move to emacs.
And I still maintain that tool tips/balloon help/obscuring the very thing you're pointing at is a stupidly rude anti-pattern. Even worse is not making it possible to turn off.
[+] [-] overgard|9 years ago|reply
Comparing unix to an IDE is like comparing a CSV file to a relational database. They both store data in tables, but you're not going to replace Postgres with grep, I hope, even though you could do very basic "queries" with grep. And unix can never be a very good IDE, comparatively, because "text streams" are not a sufficiently good data structure for representing program structure.
[+] [-] coldtea|9 years ago|reply
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.
[+] [-] combatentropy|9 years ago|reply
Amen, brother
[+] [-] qwertyuiop924|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] jimbokun|9 years ago|reply
Neal Stephenson expressed this same idea very eloquently:
http://www.cryptonomicon.com/beginning.html
[+] [-] carterehsmith|9 years ago|reply
That is good. Can you tell us, what exactly did you build with "vi + shell + standard utilities + what I build"
[+] [-] wodenokoto|9 years ago|reply
That's a really stupid requirement.
[+] [-] the8472|9 years ago|reply
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 can make accurate suggestions what can be inserted there. Saving the file while debugging automatically compiles the code, runs tests and splices it into the running VM so you can continue debugging the running process with the new code while also showing you which lines you changed relative to the most recent VCS commit. And of course there's more.
[+] [-] qwertyuiop924|9 years ago|reply
Not to mention, compared to most IDEs, Emacs is trivial to extend. You know those really simple plugins that provide a tiny amount of incredibly useful functionality? Yeah, we have those, but most of them are so trivial to implement that they're just snippets you can copy into your config. Once you get the hang of elisp, you can be writing real, useful commands in a matter of minutes. Sure, not the big stuff, but still things that matter.
[+] [-] amelius|9 years ago|reply
[+] [-] lloeki|9 years ago|reply
Arguably, to me, they are because making the tools produce results together through composition is a first class construct of the shell and vim/emacs.
[+] [-] qwertyuiop924|9 years ago|reply
...Well, this is clearly a Vim user. If you're never leaving Emacs, and you're writing plugins to do everything inside it, you're using Emacs exactly as intended.
[+] [-] npsimons|9 years ago|reply
"It was all just text. Why did you need another application for it? Why should only the shell prompt be editable? Why can’t I move my cursor up a few lines to where the last command spewed out its results? All these problems simply disappear when your shell (or shells) simply becomes another Emacs buffer, upon which all of the text manipulation power of Emacs can be brought to bear."
[+] [-] clifanatic|9 years ago|reply
(ducks)
[+] [-] tychuz|9 years ago|reply
:-)
[+] [-] _vya7|9 years ago|reply
[+] [-] BjoernKW|9 years ago|reply
[+] [-] cathexis|9 years ago|reply
[+] [-] jcoffland|9 years ago|reply
This depends a lot on the user. In the right hands it's extremely efficient.
[+] [-] pmiller2|9 years ago|reply
[+] [-] DonaldFisk|9 years ago|reply
[+] [-] polpo|9 years ago|reply
[1] https://en.wikipedia.org/wiki/The_Unix_Programming_Environme...
[+] [-] pvg|9 years ago|reply
[+] [-] sedachv|9 years ago|reply
[+] [-] rbc|9 years ago|reply
[+] [-] julbaxter|9 years ago|reply
[+] [-] cdevs|9 years ago|reply
[+] [-] beachstartup|9 years ago|reply
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
[+] [-] a3n|9 years ago|reply
Learn to speak vim — verbs, nouns, and modifiers! https://yanpritzker.com/learn-to-speak-vim-verbs-nouns-and-m...
"To move efficiently in vim, don’t try to do anything by pressing keys many times, instead speak to the editor in sentences
" delete the current word: diw (delete inside word)"
[+] [-] lucb1e|9 years ago|reply
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.
[+] [-] signa11|9 years ago|reply
[+] [-] shunyaloop|9 years ago|reply
[+] [-] emmelaich|9 years ago|reply
https://en.wikipedia.org/wiki/PWB/UNIX
It introduced version control (SCCS), make, lex, yacc and more.
[+] [-] imtringued|9 years ago|reply
[+] [-] leonardinius|9 years ago|reply
[+] [-] justinlardinois|9 years ago|reply
[+] [-] jxy|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]