Unix as IDE (2012)

Unix as IDE (2012)
blog.sanctum.geek.nz

It turns out, however, that we haven't really strayed far from the "Unix as IDE" approach, as in order to turn Vim or Emacs into an IDE the typical approach is to just use Unix primitives and make the editor into a sort of super-shell that orchestrates pipelines of processes consisting of Unix command line tools. And that's fine.

Time has marched on, however, and we have been the lucky recipients of not only better IDEs than Unix, but also things that are better than Unix at what Unix was thought to do well. PowerShell, for instance, is a vast improvement over Unix command-line environments with its ability to operate over typed pipelines of objects. We should be expanding our horizons beyond what 1970s programmers found convenient to implement and embrace new ways of thinking about, writing, testing, and debugging code.

But in practice, I could never get as efficient with it as I could with "the Unix way" (everything is a string).

If I was writing a "production" script, then it's better. But when I'm just trying to quickly do something on the command line, the "everything is a string" approach is good enough.

Also, now with an IDE, code completion is table stakes and we are moving toward LLM integration where the IDE will assist in coding.

The Unix pipeline model is not suitable for this as you need persistent processes and low-latency two way communication.

It is interesting to note that the Language Server Protocol which is the biggest innovation in terms of scaling language completion across multiple languages and editors came from Microsoft.

We are moving into a world where although the code is stored as text, our programming tools understand and manipulate it at a deeper level than just a sequence of bytes which is what the Unix tools do. Rename that uses the AST is much more safer and powerful than sed. Context aware search is better than grep.

You're right; we should be going back to the Lisp and Smalltalk machines of the 1980's.

In that sense, I've found PowerShell to be something of a letdown. I was hoping for something that was an ergonomic abstraction over NT's primitives (or Linux's) and over the CLR's primitives at the same time, in much the same way that Lisp worked on Lisp machines, but PowerShell is only frustratingly alright at both.

With the deprecation of the ISE, the debugging story is also something that's pulled into question. Is the VS Code extension the place to go now?

I wind up spending more time in F# because the whip-it-upitude story is a little better there, especially with the Jupyter notebook support, and the choice of using the same debugging and development tools I use for the rest of my tech stack is an obvious one.