In a way, it feels like a re-imagining of a smartphone.

Some things that caught my attention were:

The actual design of the device. One button, one scrollwheel (reminiscient of ipod?).

They also start strong, by asking the device

what is the nature of reality

and get a Russel quote back.

Then, they compare its usage, to a walkie talkie

push a button, and talk. Like a walkie-talkie

which is fascinating. Walkie-talkies are not very common nowadays.

Then they order an uber and pizza using the device, which is odd to me. It somewhat downplays the potential of the device, since this is something my smartphone can already do.

All this gets me back to thinking "how do we demo a new kind of device". Food for thought.

I guess I would, with a somewhat critical hat on, ask if it ~is~ a new kind of device. Have we not been here and done that with the voice assistant hype of the 2010s? Does being based on an LLM rather than a Siri/Cortana/Alexa style command palette really do anything to resolve the reasons those devices stuck for only limited use cases (like setting timers)?

The UX feels fundamentally the same to me, really. The only difference is it’s swapped one type of uncertainty for another: in Siri-era voice assistants, I would never be sure my request matched to a useful command. With LLMs, I’ll never be sure what it gives me in response isn’t garbage.

Indeed, hence "new kind" in quotes. The functionality is very much a subset of what a smartphone today can do.

Then again, they market it as a new kind of device, which is emphasized by the fact that it looks like nothing else to me.

I'm left wondering what the audience of this is. Should I replace my smartphone with it? Is it something to keep at home where it happens to be useful?

The UX feels fundamentally the same to me, really.

Yes, with the important distinction that you can't fallback to setting the timer yourself.

edit: i guess the same applies for alexa "can" and other devices.

which is emphasized by the fact that it looks like nothing else to me

there is one device it looks quite a lot like…the Playdate. They apparently consulted with Teenage Engineering on the r1, who designed the playdate’s hardware, and to me it feels a lot like TE has just sold them a barely modified playdate chassis. My pet theory on the scroll wheel is it’s another piece of plastic on the Playdate’s crank

play.date

Interesting. Should have checked the TE catalog.

The 360 camera is cool though, reminds me of the very early (and sadly doomed) Notion Ink Adam tablet

Also reminded me of this early LG flip phone with rotating camera.

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…

• 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.)
• 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?

But text is awesome. I think it's good to have courses on dealing with text even if you like paintings.

Maybe this comes back to my criticism of the idea expressed in the foc podcast that films are novels plus more, rather than a deep and complex tradeoff.

@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.