Text Editor Debate

There was a listener question posed on Coder Radio 477 that asked: dafuq with the vim an shit, bruh?

Having edited code since about 1988 (DOS 3.5 Bible era) and actually having taken classes programming in OG Unix (SunOS 4.1, 1993) before the time of vim, there was Bill Joy’s vi. But around that time, Borland (just 15 miles away from UCSC where I was a student) was selling Turbo Pascal. This contrast tells the story of programming environments from early days: the resource constrained v. personal system.

Resource Constrained

Multi-user, corporate or university environments had, and continued until the mid-1990’s oriented around terminal-based computing environments. This environment was very scale efficient for campus sized needs. Constraint focuses creativity, and as such, it focused problem solving over experience and exploration. Editors like emacs, vi, jed, joe were all sprouted from a server-centric model where bandwidth was poor (2400bps, eventually 56kbps) and keystroke efficiency was a primary priority. Keep in mind, previous models of multi-user environments were punch-card/tape and teletype models that destroyed paper at a prodigious rate…at 300-900bps.

System administrators to this day benefit from the tools (vim, emacs, nano) that can operate in reduced bandwidth environments. Those environments are commonplace still: embedded machinery controllers and routers, wifi access points that have tiny memory space. Operations that require remote access over vast distances are typically restricted to low bandwidth: 3G and 4G network bandwidth might be at modem speeds (128Kbps), satellite based access might be at 512Kbps-1Gbps but might be subject to 120ms+ delay, limiting interactive communication. These environments will never not exist, and we will always need proven ways to administer remote systems.

Local Systems

Desktop processing was not subject to multi-user constraints or restricted bandwidth. The Borland compiler tools in 1993 were informative with compiler errors, including common causes and solutions. The Visual Studio tools from Microsoft in the early 2000’s demonstrated how to create user-focused software that helped navigate complex libraries of software, easily solving the problem with the outsized local processor and memory resource common to consumer PCs.

The post-AT&T Unix based workstation environments (Solaris, HPUX, Silicon Graphics IRIX, NeXT) all invested substantial amount in programming environments. What those platforms lacked was consumer ubiquity. The moment Intel CPUs outpaced SPARC processors, the final nail in the coffin was driven. All those very sophisticated programming environments would never be seen again.

To poke a sharp stick into the side of the irony bear, the two most memorable consumer programming environments became Basic and Apple Hypercard: the basic DOS edit editor and Apple’s basic visual programming environment would have more impact on consumer adoption of small-business program development for the next decade than any C-based programming language until Javascript.

Present and Future

No one dies in this story! Every enterprise and small business is motivated to keep the oldest environment operating until there is no one left to maintain it. Even in 2010, I saw small businesses continuing to cultivate 1980’s era Fortran systems that took most of a room to house. This forces the employees to learn the terminal. At the same time, Visual Basic was still being used to program CAD/CAM machinery across the street. What did they program in? It might have been Notepad, or possibly BBEdit.

Both environments live by necessity. Businesses that require quick adaptation to a large code libraries benefit from tooling that enables exploration. Exploration helps the maintenance programmer quickly build the mental class hierarchy. Thus IDEs like IntelliJ and Visual Studio help navigate moderate to complex development tasks.

However, IDEs are frozen in their support–limited to the languages and projects they are configured to serve. System administrators are responsible for editing a very dynamic selection of file formats that are not bounded by any project architecture! Thus, text editors with syntax highlighting benefit their tasks more. Do you need to edit VB6 code, Batch files, and PowerShell scripts? A Microsoft oriented tool like Notepad++ might be sufficient. Do you edit files over sftp, webdav or other remote connections? Web-enabled editors like Bluefish might be more your style. Are you editing YAML files for netplan? Are you editing dnsmasq.conf, resolv.conf, httpd.conf, my.cnf and .ssh/config files? The versatility of a highlighting text editor is invaluable for those tasks.

But you are editing them remotely. Remote editing is crappy over a VNC or RDP desktop session and you naturally prefer an SSH terminal connection. This is where vim, emacs, nano or jed support your needs: syntax highlighting for well-known files, edited on low-bandwidth links. Like a pro!

%d bloggers like this: