TL;DR: many computing applications have transcende...
# thinking-together
j
TL;DR: many computing applications have transcended files-and-folders, why haven't developer tools? šŸ¤” During Papers We Love Education yesterday, we were joined by a couple of teachers of various age groups, and I had the opportunity to ask them about whether they've observed what this Verge article describes: https://www.theverge.com/22684730/students-file-folder-directory-structure-education-gen-z The article is about how ubiquitous search and cloud storage have meant that young folk no longer have a mental model of file systems, or really understand files and folders. I had suspected I was observing this in my work, with some of the questions I was getting in our introductory content about CLIs. The educators confirmed they're also seeing this and it's a big problem. That struck me as a big issue for CS education. If students are coming in never having interacted with an app that deals in files, saving files, or organising content in directories, that's a huge hurdle to beginning programming, or interacting with most tools. Everything we do and use still has the file system at the centre of the experience and the interface. Whether the ā€œtabletificationā€ of computing is a positive thing or not, it's interesting to me that unlike many categories of applications, developer tools, even for young learners, have resisted it
j
Good question. I was excited by WinFS when it was first announced, but it never made it to market. Maybe it would resonate with the "non-files" crowd today,
w
Aren't developers (UNIX developers) the ones who invented files and directories in the first place?
g
multiple processes have to operate on the code. Examples are: version control, compiler, and ide. Some people may want to use a tool you haven’t heard of or don’t exist yet. All these iOS apps operate like little islands where the author has to export the data from one app to another to do different tasks.
k
There are good arguments for and against filesystems, which carry different weight for different applications and/or user profiles. So why should one expect developers to manage data in the same way as the users of their applications?
šŸ‘šŸ¼ 1
n
@George A file system is essentially just an app too. It's an app that allows you to store and retrieve data via a GUI interface or a programmatic interface. The only real benefit (or unfair advantage?) it has is that every programming language/environment has built-in APIs for interacting with the app. I think the right path forward is for OS developers to abandon the idea of a file system as a ā€œblessed appā€, and create better and more general ways for apps to share data directly with each other. Mobile OS’s have been heading in this direction for a while. This will make the ā€œdesktopā€ metaphor entirely obsolete, but that's ok. I'd say its time has passed.
a
It's probably overreaching to say that search-based interfaces are inherently more abstract than filesystems, but they are certainly inherently abstract, and presently more abstract than filesystems. Dev tools face a pressure to be low-abstraction, because we never know what weird detail is going to get picked up and branched on by our eldritch runtime stack of OS, language VM, etc. For that weird detail to be invisible because of our shiny UI is intolerable. This kind of thing already happens far too often for my taste. My dev tools need to be an anchor in this ocean of insanity, not another contributor. So I think dev tools, at least for professionals and those who wish to be such, are unlikely to change and absolutely should not change until the underlying OS does. I also reject the notion that "smart college students" are incapable of learning a hierarchical file system. If they're not getting it, you're doing a bad job teaching it. (Granted, the attempts of mainstream OSs to split the difference don't help, with multiple dumbed-down views onto the same tree. Funny how devs gravitate toward OSs that make that tree easier to see.)
šŸ’Æ 1
w
@Andrew F, "we never know what weird detail is going to get picked up and branched on by our eldritch runtime stack." In contrast we have the lie of WYSIWYG tools where some aspect of the WYG is hidden deep in a sub-sub menu panel or actually, truly invisible.
k
@Nick Smith What does a "better and more general way for apps to share data directly with each other" look like that isn't "essentially an app"? Or did you mean a file explorer rather than a file system? Calling file systems apps feels not even wrong. Syscalls are not apps. The big difference between system software and application software is one of incentives. An OS maker needs people developing apps, and so has an incentive to standardize and maintain interfaces independent of products or apps. Two apps interchanging information often lack such transparently aligned incentives.
n
@Kartik Agaram
What does a "better and more general way for apps to share data directly with each other" look like that isn't "essentially an app"?
My vision for inter-app communication demands that apps exist in a wholly new (i.e. not-yet-invented) operating environment that offers a novel model of data communication. The model will not be message-passing (i.e. syscalls, APIs, etc); it will be something closer to shared immutable state. But the details are unimportant here (and I'm still working on them). My main point is: this would be the "standard" you are speaking of, but it involves no "intermediary app", and it involves no "central file system". (After all, have you ever heard of an immutable file system?)
j
@Andrew F I don't know if anyone is saying they're incapable of learning it. It's just a challenge, when a fundamental mental model that previously all students had needs to be taught. A pre-requisite becomes part of the course, and room needs to be made for that in the limited time the educators have with the students. One of the high school educators on the stream we were discussing this on made a comment to the effect of: CS classes are increasingly teaching digital literacy skills that used to be addressed elsewhere.
w
Like @Kartik Agaram says with "Two apps interchanging information often lack such transparently aligned incentives." Apple at least wants apps on their platform so that they can make their devices essential and charge rent. Facebook, on the other hand, has very little incentive to have people use any software, site, or service but their own.
@Joe Nash says, "teaching digital literacy skills that used to be addressed elsewhere," and the letters AUTOEXEC.BAT flash through my mind.
ā¤ļø 1
šŸ˜‚ 1
r
Never underestimate the power of Worse is Better! Files and directories, especially in the Unix tradition, are the simplest level of object that can be meaningfully shared between programs. The issue is that a file is just a stream of bytes to whoever reads it; the knowledge of how to turn that into information stored separately, which makes interoperability buggy yet still feasible. Instead of a stream of bytes, maybe files can contain the behavior that makes them information bearing objects, so that an unforeseen consumer doesn't have to write more string munging routines, just send a message. This has to be consistent and ubiquitous from the bottom up in order to work, which requires an operating system alien to the current ones we use and more like Smalltalk. Filesystems are really just trees (DAGs if you add in symlinks (that don't create cycles please!)), so representing, traversing, and serializing them shouldn't be infeasible in a language that elevates the file to an object. This also opens up the possibility of distributed object spaces in the vein of Jini/Plan9, where access across machines/networks can be mediated mostly transparently, especially with some notion of capabilities, which file systems already have a primitive level of in W/R/X permissions. The possibilities are endless, which is probably why so many people get lost and we remain in the enduring 70s frame of Unix.
😭 1
a
@Joe Nash Fair, they're not outright saying it's impossible, but I think the last quote on the article about "get used to it, this is not going away" absolutely represents despair toward actually accomplishing it. And yeah, despite all our big dreams, filesystems aren't going away either, at least not soon enough to give up on teaching people how to use them.