@natecull @teleclimber gamewise i don’t see anything here you couldn’t do in a browser. but with deno you’d have to a do a bunch of extra setup. deno is very much about correcting the mistakes ryan dhal thinks he made with node, and thus it’s squarely in node’s original usecase: small realtime server. though i see it’s got an api that shows it could do electron’s job.
It might be because "just plain browser" got a very bad name back in the IE vs Firefox wars, and so everyone ran for the shelter of frameworks as protection against all the unimplemented and half-/buggily-implemented browser stuff? And now that "framework first" mentality has stuck?
just utterly insane things like, there's no builtin functions (or at least not sensibly named, easy to find ones) to test whether an object is an array, is Null or not, fallbacks for Null handling, vanilla 'sort' is DESTRUCTIVE, yeeeeagh. Things that, if you're doing database-query type stuff, you just don't want anywhere near your code.
It *hasn't* been fixed. Or rather, the dangerous, unsafe stuff is still there right alongside the correct stuff.
So, much better to never trust the builtins, just indirect everything through a different namespace. Otherwise for every single method call you have to go 'is this one of the good ones? or the evil ones?' and you'll occasionally get it wrong.
I can (and am looking at right now) run an entire emulated BBC Model B Computer running a BASIC adventure game in the browser... except there's no way of saving the game because, shrug, browsers aren't allowed to write to the local filesystem. Even just to one designated file selected manually by an out-of-browser 'file open' dialog box.
I guess I'm getting my information from nobody ever using it! Like, for instance, Tiddlywiki writing a whole baroque EXE plus plugin system to implement saving!
So it's there and it works? Cross browsers? And we can save files in it? And remember the file name across browser invocations?
like I wouldn't mind if, eg, I had to manually associate any given URL with a local folder, and then it couldn't ever access anything outside that folder (unless I manually accessed the file navigation UI, which the browser wouldn't be able to fake). I think I could cope with that level of manual intervention and I think that would give enough security maybe?
@natecull @teleclimber see i am a bit of a radical and i think fundamentally filesystems are a bad idea and if we can avoid ever using them we should. the main reason we are still kinda forced into using them is it’s the only non limited way we have of sharing information between systems, so if someone forward thinking like apple stops us from having a “real” file system it can feel like handcuffs when we want to get data in or out.
@natecull @teleclimber of course apple caved, and as a result i now need to choose from like 8 different ways to handle images i want to download, when in the good old days the image would just go to my photo roll and that would be it.
sure it sucked when i got a link to a zip file and there’s still no good way of dealing with those on iOS, but i’d prefer it if we were thinking up nicer solutions instead of just rebuilding 1980s ideas.
I wouldn't, in principle, be *completely* against replacing filesystems, with some kind of object store, as long as
1) I can still preserve my data as readable and transferrable to other media on a timeframe of at least several decades
2) access to my data is not gated through any Internet-connected entity.
I want the right to have my data stay physically local to my machine, and the right to copy and move it onto physical media.
If we had some kind of 'object soup' instead of a filesystem (maybe with files grandfathered in as one object type?), I think there'd need to be a way of isolating all the connections from any given recursively contained part of that soup, to others.
So that we could get the equivalent of 'copy just this one folder', which I think is a really useful semantics for information sharing. If we had that plus '... and all the objects referenced from it', it might be cool.
@natecull @teleclimber the appealing thing about a file is that it’s a fucking thing. humans can deal with fucking things. we can’t as easily deal with giant webs of interdependant references, as i’ve seen you musing about.
the mac classic file system was really something though. each file could have a blob of data in it, sure, as you expect, but each one also had a database associated with it. if you’re an app developer you could just write to that database, and that’s your “file”
@natecull @teleclimber so you could really split the concept of “file system” into two peices: the physical inplementation, and the UI that presents users with “things”, and the list of affordances those things permit. the physical implementation of the thing doesn’t really need to be a stream of bytes.
Agreed, a stream of bytes is not very wonderful, it forces every program to be its own from-scratch parser, which is a hassle and a security nightmare.
I wonder though if we could do something like I'm suggesting (eg: gather up all the external references and bundle them together) for object-soup systems. I feel like it would solve a lot of issues we currently have with package management, version control, etc. The same pattern happens again and again.
like imagine if you could just copy a local HTML file to an external drive, and the act of doing that did a wget on all of its links and bundled those with it. Something like that. Only not HTML, with JSON or Smalltalk or the equivalent, and maybe with some sanity checking so there's a maximum size it will try to bundle.
Yeah, boundaries I think always were the problem with Lisp and Smalltalk systems too. Why 'images' became the format and were seen as too cumbersome compared to files... ... but now with file-based systems being not just one VM but whole clusters of VMs, it's not enough just to give someone a VM, they need the whole meta-environment that can launch that VM .....
It seems like a similar problem to, what if I did the 'Zettelkasten' technique and had one big card file for all my personal information. Then what happens if I want to give part of that to someone? Is it possible to cleanly partition a card file? Which links is it okay to keep hanging?
@natecull @teleclimber i feel like maybe this was the missed lesson of smalltalk’s OOP. not that I’ve used it, but i think the idea was an “object” was supposed to be “the fucking thing”, and that you should be able to expect to pick up an object, stick it in an entirely foreign system, and have it just fucking work without it complsining about missing libraries. that the boundary of the object is message passing, not binary or lexical linkages. like the js worker api.
But of course it turned out that an object always relied on a whole bunch of other objects, and there was no way for objects to 'literally contain' other objects other than just referring to them. So we got all sorts of non-object metaphors for 'containment'. Modules, libraries, packages, projects...
you could do all that same stuff in a single process of course, but if it’s possible to just passively reference something, you definitely will, instead of designing a protocol for communication with the thing using messages.
@natecull @teleclimber so, i think that’s the key is if you want a thing to be self contained, it can’t reference or depend on anything, and where possible it interacts only with the outside world via messages.
it’s still possible to build a house of cards out of that but the goal would be to design the system to make not doing that the easier choice
Is there anything *wrong* with just passively referencing something, though?
I suppose the genius of Smalltalk was to make the idea of message-passing nearly invisible: you had what looked like just a reference (and in C++, compiled down to pretty much just a pointer) but, supposedly, you got the rich message-passing semantics. Best of both worlds.
Except maybe we didn't quite know what semantics we actually needed for our messages? And still don't?
like I can write a system which is based on messages to the Google API, but if one day Google change their API, whoops, it still sends messages but nothing works.
That exact thing happened to the "Smart TV" with a Youtube app that we bought in 2012. TV still works, app does nothing because Google changed the Youtube API.
@natecull @teleclimber that is an important and relevant point. which is why there should be a set of *standard* apis but there isn’t because kyapityalism. if youtube goes down i should be able to just plug in the url for vimeo or whatever and everything works the same.
to be fair, there is dlna, but i guess it’s long in the tooth.
APIs are contracts. promises. a changed api is a broken promise and should be treated with the same social stigma.
@natecull @teleclimber but we don’t have anything in the api world nearly as ubiguitous as say, jpeg is for images. or unicode for text. http is sorta it but it does not cover use casss like “streaming video service”, and we likely won’t have that because many people’s salaries depend on us not. but for other common use cases there should be like, standard name recognised things for photo galleries, music libraries, etc. and there kind of is but the landscape is neglected
and then if you copied that folder back into another system, it would only merge in the objects that were new, and hopefully it would also record that this was one atomic changeset and let you back it out.
That's probably where the problems come in, I guess. What happens when there are changes, and if you back out a prior change but want to keep later ones...
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!