
Unix as IDE - yarapavan
https://sanctum.geek.nz/arabesque/series/unix-as-ide/
======
__jal
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.

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

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

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

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

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

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

~~~
ktRolster
"My primary debugging tool is Console.Writeline(). To be honest, I think
that's true of a lot of programmers." \--Anders Hejlsberg

If Anders Hejlsberg does it, there's no shame in it.

~~~
RX14
There's no shame in it but that doesn't mean that it's the best or most
efficient way of doing things.

I've found that stepping through code in a debugger at a human pace, and
getting to really understand what's happening when a bug occurs is invaluable.

~~~
reddit_clone
I don't trust debuggers with multi-threaded programs.

Organized (multi verbose level) tracing built right into the application can
go a long way before you actually need a debugger.

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

~~~
npsimons
[http://blog.vivekhaldar.com/post/3996068979/the-levels-of-
em...](http://blog.vivekhaldar.com/post/3996068979/the-levels-of-emacs-
proficiency)

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

~~~
qwertyuiop924
This is Atom's great failing: it's trying to do the emacs thing, but it
doesn't treat all buffers uniformly: your settings window, your terminal
window, and the various text windows are fundamentally different. Until this
is fixed, it's not even in the running as a usable editor for me.

~~~
zeveb
> This is Atom's great failing: it's trying to do the emacs thing, but it
> doesn't treat all buffers uniformly

That's definitely _a_ great failing, but I think it has two greater still: not
being written in Lisp, and being written in JavaScript.

The former could be overcome (Alpha was an amazing editor for the Mac written
in TCL), and after all there are plenty of great programmes not written in
Lisp (emacs, for example, has a C core …).

But JavaScript‽ JavaScript: there's got to be a better way. JavaScript: warn
your friends about it. JavaScript: dissatisfaction guaranteed.

~~~
qwertyuiop924
JS is fine. It's got warts, yes, but so has elisp. It's also got proper
lexical scoping, and real, function-equivalent lambdas, which are surprisingly
rare.

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

[1]
[https://en.wikipedia.org/wiki/The_Unix_Programming_Environme...](https://en.wikipedia.org/wiki/The_Unix_Programming_Environment)

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

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

~~~
BjoernKW
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).

~~~
wott
Almost all 8-bit computer were like that.

I was so glad when I left REPLs and then debuggers and IDEs, to compiled
languages and text-editor + command-line compilation and open source-code. I
just cannot fathom the trend of the last 5 years where I hear and read people
who cannot live without an IDE, a debugger and a REPL. It feels like living in
a jail cell for me; a cell I left 20-25 years ago.

Incidentally, I just had to install an IDE today, for HDL development. I
urgently have to find a way to turn the process into a Makefile or I will
throw the computer through the window before the week-end comes.

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

------
julbaxter
Previous discussion
[https://news.ycombinator.com/item?id=4105768](https://news.ycombinator.com/item?id=4105768)
and
[https://news.ycombinator.com/item?id=3594098](https://news.ycombinator.com/item?id=3594098)

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

~~~
beachstartup
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](https://en.wikipedia.org/wiki/Vi)

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

~~~
beachstartup
yeah, it's pretty awful.

------
signa11
iirc (very vaguely) this has been discussed on hn before. the entire series is
available as an ebook here: [https://github.com/mrzool/unix-as-
ide](https://github.com/mrzool/unix-as-ide)

~~~
shunyaloop
Thank you. The ebook is helpful

------
emmelaich
A early variant of UNIX was explicitly that. But it was called Programmer's
Workbench.

[https://en.wikipedia.org/wiki/PWB/UNIX](https://en.wikipedia.org/wiki/PWB/UNIX)

It introduced version control (SCCS), make, lex, yacc and more.

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

------
leonardinius
Shouldn't there be (2012) in the title?

~~~
justinlardinois
Yes.

------
jxy
I thought this is another acme post. Oh NO~~~, you don't even use a mouse?!

