<< The average person tends to have either less than eight tabs open, or to add tabs without organization until declaring “tab bankruptcy” and starting fresh. >>
yeah, I'm the... second one
(checks browser; it reports 'new mathematical research needed in order to determine if your number of open tabs is even theoretically countably infinite')
@natecull i obstinately refuse to ever close tabs even while my computer struggles and furiously diskswaps.
freeing up space memory and cpu time sounds like the garbage collector’s job. why is my computer making me do its job?
@zensaiyuki exactly how I feel, yeah.
I end up restarting Firefox instead of closing tabs
because I *might* need one one day
@zensaiyuki Actually, it's far worse than that.
The act of clicking on a tab to close it means i'm likely to read the page again, and then I'm likely to click more links. Into new tabs, of course.
@natecull i sorta want a browser with a different UI paradigm where pages exist in a kind of zoomable space, history stacks are visualised as skeuomorphic stacks of paper, and “new tab” just makes a new stack. a heuristic dumps old stacks to disk so they don’t consume memory or cpu, but if you go back they can rehydrate, and ideally not in a way that is effectively reloading the page, though that might be unavoidable.
@zensaiyuki That's a (large) part of what this is all about:
"What if the Web were filesystem accessible?"
It's kind of relevant, at least to my interests.
My 'webscape' is my set of open tabs, but only because that's all today's browsers give me. What I *really* want is yeah, massive and pervasive caching. Everything I've ever browsed, I want it downloaded and not to hit the Internet again unless it absolutely needs to. And then I want to search that stuff locally.
Today's browsers assume 'stuff lives primarily in the cloud/web,' but I want the reverse of that.
Hmm. I wonder if just automatic saving of all web pages to a file/folder, plus a file containing a history of URLs.... wouldn't go a very long way towards this.
perhaps even just a local web proxy service, implemented in Node.js
The point is its database should be engineered for maximum accessibility of data by other applications. So a filesystem, for preference, not a database.
ooh, literal dream projects! I like those.
I had something similar happen to me around 2006. Still don't quite grasp what my dream-self was trying to express.
(although a large part of it seems to have been 'functional reactive' before that became popular with React.js and Elm... sadly, I didn't have any way of expressing what I want, and I still don't quite grasp what the core elements of FRP are)
My gut feeling though was and still is that we ought to be able to make both GUI and network programming much, much simpler than they are by expressing them as declaratively as possible and letting a simple runtime engine stitch together dataflow paths.
How exactly that runtime engine works, though, my dream-self left as an exercise for the reader and so I still don't have a handle on it.
Something like 'pure-functional reactive RDF' was my feeling, but... how?
the whole model is that it’s like you’ve just got a pile of functions with multiparameters and multiple returns, and the plist is just a graph of how they’re hooked up.
That sounds... sensible?
Multiple returns as in coroutines and 'yield', or something else? What specifically about FRP requires them?
(I'm not surprised that it does, because I encountered something similar, but finding that plus the general lack of interest in reliable co-routine support in most languages shook my confidence.)
@natecull @dredmorbius frp doesn’t require them, exactly. it’s just a really convenient way to model the structure of a program. in a normal program you mightget some sturcture as a return value, and a bunch of code is effectively just “glue”, parsing oyt useful results and calling other functions. in quarts compuser you just hook a wire from an output value to an input value. the essence of frp is signals. a patch bay on a synth is like frp.
I guess what I'd like to see is the simplest possible reduction of FRP to its essentials, and expressible in short program text. I don't see why it needs to be graphical (could be expressed graphically, but would be simpler to reason about if it wasn't).
So I can see 'a patch is a function' easily enough. A function from an input value a time T to an output value at time T. The value might be a structure.
But, sometimes I think it would also need access to time T-1.
So to me, one big question with FRP is 'how best to express self.state at time T-1?' I suppose maybe just as a magic variable...
But then, second question is, what happens to self.state if we disconnect and then reconnect from the input source? Is it always safe to just reset state to null?
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!