
Unix as IDE (2012) - lrsjng
https://sanctum.geek.nz/arabesque/series/unix-as-ide/
======
ohthehugemanate
I'm a terminal jockey and an i3 junkie, and for a long time
vim+extensions+Unix tools were my IDE too... but ultimately there is a
difference between a powerful editor used like an IDE, and an actual IDE.
there are lots of features which get first class.attention in an IDE, which
were just kludgy hacks in my beloved vim... and some that simply weren't
possible.

For example, VSCode Remote container development. The IDE is split into client
and server portions, with the server living in a container (or group of
containers) of your definition. So your host environment is clean, but you
still get tools that are a PITA or impossible to run remotely, like certain
debuggers or linters. And best of all, the configuration is saved in the repo.
Commit it, and everyone in your project gets a "one button option" to use the
same developent environment as everyone else.

It's not IMPOSSIBLE to do something similar with vim+Unix. Docker compose and
enough automation will get you most of the way there. But not without a
tremendous amount of work and time spent maintaining it for everyone's unique
environment. And certainly not in a fashion that i could call "one button".

There are a few features like that. So I stopped spending hours (and hours and
hours) maintaining a collection of hacks that approximated a modern
development environment, and started using software for what it was designed
to do. Vim is still my superpowered editor of choice, but when i'm working on
a significant codebase, I use an IDE.

~~~
clktmr
I tried VSCode several times, but always came back to vim. I think there is a
fundamental difference to a purely terminal based workflow.

Learning a new commandline tool has almost always been something that paid
back for years: CLI cares much more about backwards compatibility than a GUI
because it's used in shell scripts. And that's another advantage: you are only
one step away from automating stuff. A homogeneousness set of keybindings over
all applications are just the icing on the cake.

~~~
strogonoff
I use both VSCode (in Vim mode) and Vim+Tmux in my work these days.

VSCode is good for working in TypeScript codebases—I couldn't find any way to
show helpful and long TS compiler errors in Vim nicely.

However, VSCode’s terminal is semi-broken and sessions do not persist, so for
other kinds of work that might involve grepping around, running builds and
one-off data migration scripts, etc., Tmux+Vim (with respective shortcuts to
unify pane navigation) work perfectly.

------
tombert
I've gotten made fun of because I've said my "IDE" is `tmux` in the past; my
typical development environment is a tmux split, where an editor (usually
NeoVim, sometimes Emacs) does editing, and the bottom half is a terminal
running either a dev server or just the compiler command.

It's not perfect, but I like how I can basically swap any component out
(except tmux itself).

~~~
zokier
I think tmux is overrated, at least when running locally. Tiling WM gets you
the same efficient screen layout and keybind driven navigation, and it'll
manage also graphical windows that you'll inevitably end up having (like
browser). Also you'll avoid any tmux-in-tmux issues if you do connect to
remote hosts, and all the terminal features (copypaste, urlgrab, scrolling,
search etc) actually will work properly.

~~~
enriquto
> I think tmux is overrated, at least when running locally. Tiling WM gets you
> the same efficient screen layout and keybind driven navigation

Funnily, I have made the opposite path, moving from a tiling WM to tmux into a
simple xterm. Tiling wm are overrated, since tmux gives you the same
functionality, and you can detach your session easily.

What I'm sorely missing is a way to "freeze" all my tmux processes so that
they can be recovered in the case of a system reboot.

~~~
zokier
> since tmux gives you the same functionality

Unless you're browsing HN on Lynx I suspect you'll have at least a graphical
browser running, which means you still need _some_ way to manage graphical
windows, because that is simply something that tmux does not do.

Also proper WM is unsurprisingly more capable/flexible for window management
because it's not limited by a fixed character cell grid and other
idiosyncrasies of terminals

~~~
enriquto
> Unless you're browsing HN on Lynx

I actually use elinks to read HN and many sites, but I also use regularly a
web browser.

However, I try to keep web-browsing usage as sparse as possible. I launch
firefox from the terminal, browse tho wherever I need, and then _close_ the
browser window. I abhor to have a browser "always open".

------
socialdemocrat
I don't like either extremes. I quite hate working in big bloated IDEs. But I
don't like trying to accomplish everything at the terminal. I always use GUI
and shell tools together.

My editor of choice TextMate is usually launched from the terminal. I work a
lot in a REPL environment and when I get a stack backtrace my terminal program
iTerm2 automatically identifies paths in the stack backtrace, so I can mouse
click them and open in TextMate at the correct line.

I use a separate git GUI client called Tower a lot, but I also use the git
command line. I mix and match a lot.

I really dislike monolithic tools. If you try to do absolutely everything from
the CLI you get many of the same problems as in a IDE GUI: You get too much
complexity in your interaction. Too many special keystrokes and commands to
remember.

I quite like the old NeXT idea of an IDE, kind of how the old xCode was when
interface builder was a separate program. As you integrate more tools
complexity just grows.

We already have a multitasking OS with windows. We where meant to use multiple
tools and not just sit in one big maximized monolithic program.

~~~
EdwardDiego
> My editor of choice TextMate is usually launched from the terminal.

My issue is, I need an editor that knows that a field annotated with @Resource
with a type and name of SomeService foo is injected by a DI framework and
makes it easy for me to navigate to implementations of SomeService with a name
of `foo`.

Sure, I could put hundreds of hours into half-way replicating what an IDE
does. Or, I could just use an IDE that was written by people who've felt the
same pain as me. TextMate might be good for the occasional Ruby or Python
script, but even then - do I have to manually manage virtualenvs while working
on this script, or can my IDE do it for me? (Spoilers: Intellij can)

~~~
swiley
My understanding is that people who want this sort of thing use a client
server set up with a server that does all of the AST parsing and linting
separate from the editor.

I feel like there’s a weird power thing some people get sucked into that ends
in forcing everyone around them to use their preferred (often IntelliJ or
vscode) editor often via the argument that the linter configuration only works
in it.

------
istjohn
I recently discovered the "watch" command. With an autosave plugin in Vim, I
can put some "print()" statements in my code and run "watch python3 mycode.py"
in a small Tmux pane to get nearly instant feedback as I debug something. Or
if I'm refactoring, I can do "watch pytest". It's pretty sweet.

~~~
guessmyname
Using _“watch”_ [1] to run your program is a bad idea. The watch command
executes a program at regular intervals, by default it runs once every second.

What you should use instead is _“inotifywait”_ [2] to execute your program(s)
whenever there is a change. This way the program will run, for example, every
time you save your changes. There are many utilities that make use of inotify
_(the library that powers inotifywait)_ some of them are fsnotify [3], fswatch
[4] and watchexec [5].

[1] [https://linux.die.net/man/1/watch](https://linux.die.net/man/1/watch)

[2]
[https://linux.die.net/man/1/inotifywait](https://linux.die.net/man/1/inotifywait)

[3]
[https://github.com/fsnotify/fsnotify](https://github.com/fsnotify/fsnotify)
_(written in Go — golang)_

[4]
[https://github.com/emcrisostomo/fswatch](https://github.com/emcrisostomo/fswatch)
_(written in C++)_

[5]
[https://github.com/watchexec/watchexec](https://github.com/watchexec/watchexec)
_(written in Rust)_

~~~
felixhummel
If you like inotify, you might also like entr [1].

I only found out about it few days ago, but it seems nice so far.

[1]: [http://eradman.com/entrproject/](http://eradman.com/entrproject/)

~~~
bigmanwalter
Wow this is amazing. You made my day with this tool!

------
pvg
A few times previously:

[https://news.ycombinator.com/item?id=12653028](https://news.ycombinator.com/item?id=12653028)

[https://news.ycombinator.com/item?id=4105768](https://news.ycombinator.com/item?id=4105768)

[https://news.ycombinator.com/item?id=3594098](https://news.ycombinator.com/item?id=3594098)

------
RcouF1uZ4gsC
I think code completion is missing. Sure you can always try to grep your
function call, but seeing the parameters and return type of a function you are
calling as you are coding is really nice.

Also a real IDE does much better debugging. Using Visual Studio for debugging
your program is much easier than using GDB, which is probably why the more
Unix programmers use printf debugging rather than try to fire up GDB.

~~~
socialdemocrat
You can do that in a lot of editors. Don't need an IDE for that. You got
standardized language servers now which are often easy to integrate in a
multitude of editors.

But personally I don't like IDE style completions that much. In editors I
often prefer completions based on what is in the file I am editing. But I also
work a lot in a REPL environment.

I personally think a good REPL is a much better debugging tool than most IDE
debuggers.

> Using Visual Studio for debugging your program is much easier than using
> GDB, which is probably why the more Unix programmers use printf debugging
> rather than try to fire up GDB.

That does not really have anything to do with IDE vs command line. My
experience as a C++ developer for many years on Linux is that debuggers just
don't work that well. Many of the issues has to do with the complexities of
C++ and how gcc stores debug information.

Most IDE style debuggers on Linux are quite crappy, because they are slow and
undependable. Printf is faster, more dependable and gives more flexibility in
how you display data you are interested in.

~~~
macinjosh
Not sure why you're being downvoted. IMHO, printf based debugging is more
ergonomic and requires less context switching. Instead of using my mouse to
work with debugger or remembering a myriad of shortcuts for navigating through
it I can just keep typing right in my editor where I already am. For me it
fall under the keep it simple stupid category.

~~~
alkonaut
How do you add more watches (printfs) without recompiling/restarting though
(That seems like a basic requirement for calling it ergonomic tbh)

------
samsquire
What is it about an IDE that you need?

a) The ability to do an end-to-end build with one click (we've lost that with
cloud being part of the equation)

b) Guranteed buildability

c) Intellisense/autocomplete

d) Widgets that can be moved into any which way.

I feel that we're missing a trick with CI/CD if IDEs can do a end-to-end build
with one click, there's some technology to be shared or extracted here from
desktop IDEs.

~~~
alkonaut
An full build is always the easiest build.

Building as little as possible and having quick iteration is the hard bit when
you have statically typed languages and large projects. If I edit a file and
change the name of the function, the call sites should all light up with red
squiggles. In a statically compiled language. Without requiring a recompile.

~~~
jcelerier
> If I edit a file and change the name of the function, the call sites should
> all light up with red squiggles. In a statically compiled language. Without
> requiring a recompile.

which is what all IDE support ? most even allow you to automatically fix it
nowadays

~~~
alkonaut
Well it requires quite a bit from the compiler/language server infrastructure
to not just behave like a batch compiler and give up after e.g. a failed
parse. The ability to analyze incomplete or incorrectly parsing syntax is very
tricky compared to doing it in sequence parse -> analyze etc.

Many IDE's manage this but far from all _languages_ (compilers) do, simply
because their compilers are simple batch compilers.

------
saagarjha
> Some of the principles discussed here will be applicable to those using
> Emacs as well, but probably not for underpowered editors like Nano.

Nano actually can do well over half of the things mentioned…

~~~
asdff
I love nano! No 40 year old mentality with the keybinds like vim and emacs. No
text editor should require a learning curve imo. You can make a .nanorc too
and tailor your experience. Some syntax highlighting:
[https://github.com/scopatz/nanorc](https://github.com/scopatz/nanorc)

~~~
anticodon
It is incredibly sad that prejudices like "40 years old mentality" stop people
from using vim.

It's not outdated or limited, it's extremely convenient and powerful. Yes,
there's some learning involved, but after learning a few keystrokes, you
become extremely productive with vim.

nano or other editors can't even come close, because vim allows to edit the
text with the speed of your though without pressing a lot of keys.

~~~
adamskiftw
The same could be said for Emacs.

------
peter_d_sherman
Excerpt:

How is UNIX an IDE?

"The primary rationale for using an IDE is that it gathers all your tools in
the same place, and you can use them in concert with roughly the same user
interface paradigm, and without having to exert too much effort to make
separate applications cooperate. The reason this becomes especially desirable
with GUI applications is because it’s _very difficult to make windowed
applications speak a common language or work well with each other; aside from
cutting and pasting text, they don’t share a common interface._

The interesting thing about this problem for shell users is that well-designed
and enduring Unix tools already share a common user interface in _streams of
text and files as persistent objects, otherwise expressed in the axiom
“everything’s a file”._

Pretty much everything in Unix is built around these two concepts, and it’s
this common user interface, coupled with a forty-year history of high-powered
tools whose users and developers have especially prized interoperability, that
goes a long way to making Unix as powerful as a full-blown IDE."

------
samsquire
I think the desktop can be an IDE.

[https://github.com/samsquire/ideas#98-the-desktop-is-an-
inte...](https://github.com/samsquire/ideas#98-the-desktop-is-an-integrated-
development-environment)

------
simonblack
I don't muck about with having to use tabs or maybe keycodes to change the
current view(s) of a terminal/xterm.

I simply open sufficient xterms on one or more virtual desktops to cover all
of my needs.

Ferinstance: I can have the warnings and errors of the last compile displaying
in one xterm, I can be editing the relevant xxx.c source file in a second
xterm, the associated yyy.h header file being edited in a third xterm, and the
man page for a library function showing in yet another fourth xterm.

All of them immediately visible, and all of them interactive.

Unix as IDE 'just works' for me.

------
fourmyle
IntelliJ Editors just straight up not working on Wayland right now has driven
me insane. I really like Sway (i3) and Wayland is a must for mixed DPI setups.
Now I have started using Kakoune and LSP for Go and Python and it works great.
I tried Neovim for a while but having another window manager inside of Sway is
too much of a burden. Kakoune opens new windows in Sway (or tmux). Combined
with a plugin to make Firefox open tabs in a new window always I found my
dream setup.

~~~
EdwardDiego
> IntelliJ Editors just straight up not working on Wayland right now has
> driven me insane

Maybe don't use Wayland then. Or, at least, suffer the slings and arrows of
outrageous fortune with some grace. You chose to use Wayland, making you a
minority (Wayland users) of a minority (Linux users). All power to you to make
your own choices, but to paraphrase an old favourite - "Freedom may be
mankind’s natural state, but so is sitting in a tree eating your dinner while
it is still wriggling."

TL;DR - you choose to use tech not supported by Jetbrains, so please feel free
to eat your dinner while it's still wriggling.

~~~
fourmyle
If Firefox can pull it off so can Jetbrains. X does not work for mixed dpi and
xrandr isn’t a solution. Wayland has been a thing for 15 years. If Apple
released a new window system devs would support it why not Linux? Your view is
essentially there are starving kids in Africa so you should starve too.

~~~
uk_programmer
Because there are probably more developers using MacOS and it is officially
supported by Apple. Wayland may have been available for 15 years but it isn't
defacto (doesn't work with the nvidia driver).

------
luord
I only started using vim constantly around a year ago because I wanted to get
used to it in case I needed it. Now I only use the shell for development and
haven't touched an IDE or graphical text editor in months.

This is a treasure trove, there are quite a few tools I wasn't aware of that I
shall start using consistently now.

------
superkuh
I go further. Unix is my IDE and my CMS for my website.

------
archarios
anyone figure out how to do this with Java though? Seems more feasible for C
or Go but not all..

~~~
fourmyle
There are language servers for Java now for auto complete in Vim etc.

------
fit2rule
Rule #1: Use all the Things.

Rule #2: vim is all you need.

