This Modern Plain Text Computing course at Duke has a refreshingly frank description written by Kieran Healy. I can't tell if I should feel positively, negatively_,_ or overwhelmingly negatively — double adverb_!!_ — about the existence of this course, though.

What, no SNOBOL? 🙄😉

All I can say is wow. I understand completely why this is necessary and useful. I also think it can be a great design exercise to think of this list as anti goals... can you design a system without these concepts?

Thanks for sharing! There might be some interesting psychotherapy to do here. My main reaction to this course is pretty positive, cuz… 1. It’s a course for social science researchers, intended to demystify computing and give the researchers more powerful tools to do their work. (In this sense, it’s similar to the workshops run by the Community Data Science Collective, which I’m friendly with.) 2. The course isn’t just a grab bag of random tips; it appears to actually teach (with historical & social context!) the “UNIX way of thinking”: shells, files, text, processes, pipes, etc. This is a coherent system with a lot of interesting underlying principles. I’m delighted by the thought of social scientists engaging with this system. I wonder what they might think of it & how it might change their thinking. But it’s clear that this class provokes very different responses for other people! I’d be curious to hear more about that.

I think it looks really good and useful

I have been teaching similar courses for students in physics, chemistry, and biology. Initially with the Carpentries, a grassroots movement that recognized that this kind of training was necessary but not proposed by universities. More recently, as a MOOC in the context of the growing reproducibility crisis in science. I feel the same tension as @Ivan Reese about this. I wish that (1) such courses weren't necessary beause of sufficient computational literacy among students and (2) we had more human-friendly technology that young researchers could grow into. And I actively work to make (2) happen. Ultimately, I see no contradiction between teaching old tech for immediate application and developing new tech that will hopefully replace the old stuff one day. Each problem must be solved on its inherent time scale.

I don't think you can create a system without many of these concepts. Like naming things, that feels essential to being human. Finding and inspecting things also feels essential and timeless, even if a terminal is less so. So this is interesting, I think, precisely because it articulates why you should want to learn specific technologies, as the state of the art in the direction of something more timeless.

This is an aspect that I have been trying to emphasize more and more over the years. It's not easy when you have little time for a course. You can't skip the technical details of getting things done, because then the students have no immediate benefit for their daily work, and that's what they come for. But if you have to dedicate one day to the git command line intricacies, and two days for the complete course (as with Software Carpentry), then there's no time left to explain the concepts of version control. That's the main reason why I am not motivated any more to do short courses.

The course itself is probably an unalloyed good. The course appears to be focused on the needs of its students, and the students are probably better off taking it than not taking it. I suspect that Ivan's misgivings are related to the centralizing of text and a text-based interface. Within text-based interfaces, however, Unix provides a particularly dynamic and flexible experience. Although the individual tools are mostly written in C, which is often viewed by dynamic language hackers as a language for building dead things which cannot be changed or restructured without killing the program and rebuilding it, the shell environment itself allows for easy experimentation and exploration. Pipelines and filters are one of the most successful composibility and component reuse stories in history. Most filters are purely functional in the sense that they will produce the same output if given the same input. This makes them easier to reason about both individually and collectively. It's easy to experiment with small one-liners, and when you finally get them right to save them into a shell script. The interface for doing things is the same as the interface for saving instructions to do those same things, which makes the transition from being a user to being a programmer gradual. There is no one place at which a Unix user must stop interacting with the system for a while and go spend a few weeks "learning how to shell script" before they can take the next step. You don't need to learn how to write a loop until you need a loop, for example. The fact that data is mostly represented as plain text, and the user has a wide variety of extremely powerful tools available for manipulating plain text, that are infinitely composable and flexible, purely functional, and easy to reason about, in an environment that allows a user to easily save and reproduce a series of steps, gives the experienced user an incredible amount of power at his fingertips. An advanced Unix user can sometimes perform in seconds data analysis tasks that would take the better part of an hour in a spreadsheet. Although these tasks could, in theory, be automated in a spreadsheet using VBA or some such, in practice they are typically written down in natural language and followed manually the next time they need to be reproduced. I'm not criticizing spreadsheets. They are also an incredible historical success. I'm praising the power of Unix for some types of tasks. I wonder why so many graphical programming environments (Scratch, Snap!, Blockly, etc.) create graphical representations of algorithmic structures, like if statements and for loops, but not data flow pipelines... I wonder what a graphical version of Unix shell scripting would look like.

Yahoo pipes maybe?

@Alex McLean

Yahoo pipes maybe?

I remember hearing good things about it, but I never did anything with it since it was both proprietary and cloud-based. With shell scripts, I have a local copy of my work and it will keep on working regardless of what services Yahoo shuts down. If I understand correctly, everyone who invested in Yahoo pipes lost all their work when the service was discontinued. But maybe someone will take that as an inspiration for creating a real programming environment based on data flow pipelines.

There is a big difference between “text” as a universal medium and “plain text files along with teletype emulators” as a specific rendition of software that incorporates text. We can certainly build computer systems that don’t use the latter philosophy as the foundation, but still incorporate text deeply. App level examples being spreadsheets, hypertext, subtext, etc. Consider hypertext for instance - what if a kind of hypertext, and not plain text, was the prevalent standard for representation? What if we didn’t design for teletype-style shells? The design space is pretty large here. I agree that naming, finding and inspecting things seem essential and I’m not suggesting we discard these, but rather design UI concepts that realize these general operations in new ways. I believe the unix style plain text files, teletype shells and text tools are not scalable. The easy example here is version control - git is great if you like to version text files and like to see diffs in terms of lines and characters. But if you really represent higher concepts in your text, you’ll have to do a bunch of extra mental work to translate line diffs to higher concept diffs. The ceiling with this plain text business is very low.

Version control is a nice illustration of the overall issues. It's indeed a pain to use for inherently non-textual information, but we have nothing better for that case. So the short-term choice is text-based version control or no version control. And since version control is so important in many situations, and increasingly becomes mandatory, everyone focuses on text-based representations for everything. And even if later this year someone presents a version control mechanism for, say, pictures, it won't be used unless it integrates with git.

I've been trying today to come up with a word that precisely evokes "text but not terminals".

I fully agree with Konrad's position here:

Ultimately, I see no contradiction between teaching old tech for immediate application and developing new tech that will hopefully replace the old stuff one day

I'm thinking if even in an alternative tech stack world, a course like this would be necessary? It would just teach a different set of ideas. Or is it possible to condense these ideas into something that can be taught in middle school and applied when using computers irrespective of which field you specialize in.

The terminal remains a rare env where most user interaction is trivially scriptable — "just" copy the commands you used into a new file, parametrize later. And we keep producing new CLI tools for Unix that retain that power for the user. That smooth¹ ramp from end-user to hacker is precious to me. And it's proven a surprisingly high bar to clear for less textual envs... And from the course description, it wants to teach not just those 6 ideas, but also the feeling of understandability & agency that comes from text. (¹For a weird definition of "smooth" that's full of warts.)

@Personal Dynamic Media Here's how we implemented the beginnings of a visual shell (VSH):

I think the evolution of computer tech is just the wrong way around. We started making pictures on cave walls etc and eventually developed writing. In computing we started with writing and so pictures are seen as more advanced. Really though conversational interfaces will always be a great way to explore ideas and that is going to involve composing symbols together.

Hi Beni - have you explored lisp machines like genera? In one demo I saw something that superficially looks like a terminal but isn't. One feature is it can present images. Another feature is the "previously printed text" is not static but a live view. So if you're auto completing a command that requires a filename and you have in your history the output of an

ls

, the relevant filenames become hyperlinks and you can just click on them to select them. This is because the connection between the text presented on the screen and the backing object is not served.

explored - Not enough, my closest experience was Emacs. I believe I'd be happy in a Smalltalk or Lisp Machine world (and I'm eyeing Glamorous Toolkit with envy). From that POV, Unix is just one that survived (and kinda encouraged) tower-of-Babel yet retained some cohesion & observability by forcing narrow-waist text/filesystem interfaces.

genera provided an alternative to the file-and-text-stream philosophy. clip from http://lispm.de/genera-concepts

@guitarvydas Thank you for sharing, that looks very interesting. Have you released any code, or is it still a prototype?

A sourdough starter is in the repo https://github.com/guitarvydas/0D. See the README.md for pointers to examples, documentation, discord. Most doc is in the other repo mentioned therein. For me, VSH is but an interesting, shiny bauble on the path towards more interesting uses of this tech. @Personal Dynamic Media.

I've been trying today to come up with a word that precisely evokes "text but not terminals".

"Written"?

I just noticed that the word "text" comes from the proto indo european for "weave". Hypertext makes even more sense now. https://www.etymonline.com/word/text

@Kartik Agaram heh yep! We're hosting a resident basket weaver Geraldine Jones at the moment, we have a lot to learn from the weavers..

I'm reading Hild [1] right now which is a work of historical fiction set in 7th century Britain. The noble women are all into weaving and plotting politics. And their metaphors for the most subtle politics all involve weaving. Makes me realize the extent to which weaving was the sophisticated technology of a long era. [1] As an aside, highly recommended: https://www.goodreads.com/book/show/17332243-hild

@shalabh The page you quote from Genera describes the same "sea of objects" model that is also the basis of Smalltalk. Stephen Kell has written a nice comparison of this approach compared to Unix and Plan 9: Unix, Plan 9 and the Lurking Smalltalk. Worth reading!

@Konrad Hinsen indeed - Smalltalk is also file and text stream free! While on one hand I like the sea of objects, there is something to be said for the stability of the passive filesystem. There are more than these two broad approaches though, and that's what I find interesting.