Is Text the Programmer’s Silver Bullet?

The command line and text editors retain their charm

Will programming ever depart the land of text?

I loved this article on the divides between user and programmer cultures, but sharing it brought responses on the values of programmer culture. Every time I wonder publicly about programming interfaces, or worse, suggest that graphical interfaces might play a role, I provoke a small army of people who think text is a key strength of programming. Though they sometimes wander into IDEs, text editors and especially the command line are their critical tools.

Bruce Maxwell, Professor of Computer Science at Colby College, described the power that text provides:

I’ve watched student after student come to the same conclusion that editing the text file is faster and easier and more precise. I’m not imposing my 1980′s C preferences on them; they are discovering this anew for themselves.

It comes down to this: you can create nice, general graphics tools that will let you do a certain set of tasks in a certain design space. But as soon as you have a specific idea or concept or need that falls outside of those tasks or the design space, or you want more detailed control, you fall back to the most general tool of all: a text editor and a programming language.

He’s right.

I was amazed, the first few times I attended OSCON, that the deeply-felt arguments at lunch weren’t about programming languages or principles, but about editors (Vim vs. Emacs) and about shells. The divisions among different ways to reach your text crossed language boundaries, and even varied within organizations. (Well, at least those that hadn’t standardized on IDEs.)

Most programming languages, in all their many flavors, remain text-based even if the things they manipulate are not. The logic of the Web front end is built in text – HTML, CSS, and JavaScript, for all of their differences, are all text. I loved HyperCard’s ability to create interfaces through a GUI, but fell back to HyperTalk when I needed to create logic of my own. Excel offers a framework that mixes data and logic, but again, making it powerful means that there is a text-based programming language lurking in the background. I enjoyed tinkering with Prograph, and perhaps it has a future, but it was always tinkering.

Computing shifted from numbers to text early, allowing vastly larger numbers of people to participate. While there is still a place for people who effortlessly manipulate binary and hexadecimal numbers, the vast majority of programmers work in environments whose symbols are more familiar to humans. We use those symbols in complex ways that aren’t especially familiar to people used to more traditional forms of text, but it’s text.

Text buys developers more than flexibility. Text offers a meta-level of manipulation, of search and replace, of diffs, of annotation, and of integration with a wide variety of tools. You should never write code in Microsoft Word – but I have. A JavaScript console might seem like an odd addition to a graphical browser, but it gives programmers huge power. I’m cautious about changing code with regular expressions, but it has been useful from time to time. Text editors often become development environments all their own.

In his 1986 No Silver Bullet article, Fred Brooks wrote about the many visions for dealing with the complexity of programming that couldn’t quite get there. He argued that graphical programming environments were too limited – “software is very difficult to visualize” – and that “Nothing even convincing, much less exciting, has yet emerged from such efforts. I am persuaded that nothing will.” Brooks had similarly little hope for the “exploding
researches into better programming environments… by its very nature, the return from now on must be marginal.”

Brooks didn’t talk about the power of text. He was looking to the horizon for new technologies in that 1986 paper, and had spent years in text-based systems. I think, though, that the power of text is part of the “big-payoff problems were the first attacked, and have been solved: … uniform file formats so as to have uniform program interfaces, and generalized tools.”

I may dream of graphical interfaces for flow-based programming and similar approaches that make programming more approachable to people who aren’t primarily programmers. However, it’s clear that for most programmers, programming will involve using text to manipulate computer structures for a very long time to come.

Text may be an old silver bullet, but it’s an effective one, and one programmers keep finding new ways to use.

Related

Sign up for the O'Reilly Programming Newsletter to get weekly insight from industry insiders.
topic: Programming
  • programmer

    programmers are workers, more they artisans. Each one has his own toolbox. Text is the only one format for exchange of tools that work. The users are car drivers, not mechanicians. No user will never want to go in a garage and rebuild an engine because he does not care. Remind this for ever: text is the exchange format of programmers tools that work.

  • http://dogpawz.com/ David Ihnen

    More and more of our programming work is just business rule and flow management – stuff better handled by higher level workers (analyst type position) who put together programmed primitives to fulfill business requirements. These people don’t need to be programmers on this low level text stuff – in fact, its probably better if they are not. They shouldn’t have to know syntactical bullshit in order to do it. Its a goal of mine to move stupid business rule configuration OUT of the hands of skilled programmers, by giving the analysts and managers their own graphically based structure to manage the software systems with. It doesn’t eliminate the programmers, it frees up the programmers to spend their time doing quality primitive work, instead of the glue.

    • John Cowan

      My experience is that “higher level workers” can’t do this job, because they don’t have the mindset for dealing with stupid, rigid machines in a flexible way, which I think is the essence of being a programmer. Graphics or text, syntax or direct manipulation, most people can only deal with other people, and deal with complex devices only in very limited ways. The idea of spreadsheets was to get programmers out of casual computation, but people who write complex spreadsheets are in essence functional programmers without the background and training to be good ones, and consequently the spreadsheets on which companies and governments rely are riddled with bugs.

      • http://dogpawz.com/ David Ihnen

        I admit that there is training that needs to happen – in how to map a problem to the sort of solution tree that will allow a computer to do the solution. However, that is an entirely different skill set from having the patience and attention to detail in order to deal with the syntactical bullshit of the text file paradigm. We can build tools that will put layers upon layers on top of the text files so that the fundamental logic flows can be plainly displayed and altered functionally, independently of how those things are represented in a more procedural way that is transformable to procedural machine code to be executed by a processor. Its pointless to teach somebody how to break problems down but not teach them syntax when the only thing you can do with the broken down problem is put it in syntax. We need the system that works on the broken down problem without the syntax in order to prove the value of educating people as far as problem breakdown, without needing to also teach them syntax.

  • Gavin B

    Yes Text! But bear in mind the text-editor must now do Unicode properly (e.g notepad++ on MS-WIn)

  • Clemens Ott

    The short answer is YES. At the beginning there was machine code then assembly and the C and later Java besides a few other programming languages, and the abstraction level is steadily increasing right? So the next step will be graphical. Lab View is doing it No flow is doing it and there so there are tools, graphical tools that cover part of the programming graphically and yes two things are there to look for, can the tool graphically get through the algorithm layer of a software and can the graphical language treat run time errors graphically? If it can do that then it is a point of the steps or element focus is it a single domain a multiple domain or a general programming language and my nose is itching in that direction … is going to happen. I have a feeling that the graphical language can speed programming up similar to the step from machine code to assembly and on, just not in the way you might think.