Worth reading the whole document here instead of making assumptions based on the title. In some ways the authors would recognise almost all current developer to

Worth reading the whole document here instead of making assumptions based on the title. In some ways the authors would recognise almost all current developer tools as integrated environments, even those we consider editors compare to those we consider IDEs like the JetBrains end of the spectrum. But in other ways this is about the failure modes of the UNIX philosophy. When everything is a file or streams of text, the authors point out that all you have are containers, not actual _things_. Your source code isn’t a first class citizen, and the doc mentions in passing a content addressable hashing scheme that is reminiscent of git (or the Unison language). The second part of the article might be reminiscent of PowerShell. Ultimately modern developers are very well served, but UNIX is in many ways a commodity layer operating beneath fairly monolithic development environments. But in an imagined UNIX future here you’d be able to dynamically edit your libc, and effortlessly connect and debug across multiple UNIX tools like awk, while incrementally compiling code and loading it into a running image with seamless FFI across multiple languages - a Smalltalk or Lisp machine but constructed of UNIX tools like C and the command line. That never really materialised, I certainly don’t see it in the disjointed workflows of the average vim-in-tmux developer. I don’t know if this is lamentable or not but it’s an interesting angle.