In the 90s I was pretty happy if you sat me down with a C compiler and vi. Any programmer, at least if exposed to a Unix variant of some kind, will know about the sometimes quirky but very powerful editor, vi. At UTAS as a computer systems officer (“jack of all trades, master of none”: coding, soldering, networking, software/hardware installation), I taught vi and other Unix-related topics to academics in short courses; later, as a junior academic, I continued to use it whenever on a Unix system. It may sound a bit sad, but one of the happiest 2 weeks of employment was spent in a portable office (terrapin style) with a DEC VT220 terminal, SunOS (or it may have been Solaris by then) Unix, a C compiler and vi, with which I was tasked to write the core of a student enrolment system at UTAS, still in use for several years after I left.
I also occasionally used emacs and, on pre-OS X Macs, whatever editor the IDE (integrated development environments, although I suspect they weren’t called that at the time) provided, for example: THINK C.
On the Amiga I used an editor that came with AmigaDOS (ED or EDIT was, I think, the name), MicroEMACS, and at least one port of vi. These, especially the fairly minimalist MicroEMACS, were perfectly fine for developing my ACE Amiga BASIC compiler.
I’ve also had a go at writing a simple editor or two, including one for a PICK mainframe email system I developed as an undergraduate project.
Upon finding the need to leave UTAS (due to university funding cuts around 1996) I was offered work with a Tasmanian Internet Service Provider (ISP) as a programmer and sysadmin, when things were just getting started in that area. Being paid to code in C and learning Perl kept me happy for while, although I knew at the start that I’d want something more than to work for an ISP but it was a great opportunity. Best of all I was able to provide employment for one of my former UTAS students there after I left, giving him a start in the game. There, as always, was vi, this time on FreeBSD and BSDi Unix systems.
When I started working for Motorola (and later Freescale Semiconductor) in 1997, I found a fairly even split between use of vi and emacs there (under Solaris), along with a high degree of religious adherence to one or the other, the kind of zeal that still accompanies the adherents of particular programming languages. I’ve always had a fascination for the LISP programming language, so emacs with its in-built LISP interpreter won points on that front, along with specific modes of use in the Motorola/Freescale environment.
These days I’m a bit of a generalist when it comes to both editors and programming languages (C, C++, Java, Python, R etc), although I have my favourites and those less favoured. That’s the subject of another post, I think.
On any given day, I could find myself using vi, emacs, Eclipse, Visual Studio, PyCharm and various other IDEs. On Unix (okay, Linux systems now) or cygwin I have for many years tended to use vi (okay, vim, its now dominant incarnation) for quick editing when I want an editor now and emacs for more complex editing. Despite the power of modern IDEs, they are, like modern operating systems, often slow resource hogs, and tend to leave me a bit cold. At least some of these have emacs and vi modes for their editors. There are other newcomer editors under Windows and Unix that while fine, don’t compel me to want to use them. To be fair to IDEs though, if you need non-trivial source-level debug, they’re hard to beat. Having said that, I’ll still break out a command-line debugger when it’s appropriate.
Now, as a software engineer with CSIRO, especially in Linux high performance compute (HPC) cluster environments coding in C++, I find myself using vi or in particular gvim (“graphical vi improved”) in that context more and more again. Once more I’m really loving its power and simplicity, including tags for source code navigation, split windows, and all the keyboard shortcut goodness that have always made vi fast and productive to work with. Also better from a resource usage point of view on a HPC system.
Maybe this is partly motivated by a nostalgic streak, but mostly arises from a pragmatic approach.
Anyway, sometimes improving on the past is not so easy or at best only incremental.