<< 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?
I like what Elm is *trying* to do, but, I don't think it's got there.
Elm is all based on the ML family of programming languages and those just rub me up the wrong way, because their fundamental structures don't seem recursively decomposable at runtime. Too much done by the compiler.
We need a core algorithm way simpler; about two orders of magnitude simpler.
Elm's 'records' need to be expressible at runtime; and all of the source code must be expressible in them.
(This is why I went hunting for a syntax that would let me express 'record/object' like constructs as lists, in a logically/algebraically complete manner, and got kinda lost in the implications since they don't seem to QUITE map to existing structures. A key/value store or function doesn't seem to QUITE have enough degrees of freedom to express all permutations of 'a set of Lisp Cons cells', and that worries me. And I can find no literature on anyone else doing that.)
Interesting! What does Quartz Composer do that React did badly or left out? I have no experience with react.
The thing that bugged me about Elm was just what kind of primitive 'FoldT' was... how we should track the accumulation of state over time in a FRP kernel, what primitives it should decompose into.
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.)
(The other confidence-shaking thing being that it seemed like the wiring-up graph between components would likely change over time, and I still don't understand how to handle that well, and simply. Eg if you disconnect from a stream because you've gone down the other path of an 'if' block, how do you reconnect?)
@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?
@natecull @dredmorbius yes, i struggled with that too, but i found a solution. the sources are impure and not functional when you first run them. but as soon as you do, it becomes an immutable fact that those sources had value X at T time, and as long as you maintain that link between the value AND the time, there’s nothing impure about it. and you can even use it for time travelling debugging.
Right, that's similar to what I think. But then, all our signals kinda need to be a pair of value and time, and then we need to be EXTREMELY finnicky about time synchronisation. Which, over the Internet, could be a major nuisance. Or we have to use something other than a time - a sequence number, maybe. Then what happens if the sequence number resets after a lot of messages?
@natecull @dredmorbius yyep. so i’ve been spending a lot of years squeezing blood from that turnip and got a few drops. the main important thing in my view that i’ve gotten out of it is you want these algebraic relationships to hold:
r( events , t) = statet; ri(state) = dstatet; r(dstatet, t) = statet;
@natecull @dredmorbius i forgot to explain this.
here function “r” is a functional pure reducer (or foldr) function. it takes an array, a stream, or a real time feed of real world data, to produce a flattened “state” of the world. ri takes a state and attempts to produce a lossy value which can be fed into r to reproduce the original state. there’s 1000 details but this is the essence of state management in a pure frp world.
@natecull @dredmorbius yeah, in react.js world this stuff is done by a library called redux. but redux is standalone so you can actually use it in your node projects without drinking allll the react.js koolaide.it’s basically just convenience functions for composing reducers to easily handle values that are deep heirarchical “json”.
Well ideally I'd like something that could run on a very small machine (32 bit or smaller) without big overhead, and could run a desktop, that might run for years without rebooting, and where some windows on the desktop might reflect Internet streams. It seems like that's in the ballpark of normal use these days.
@natecull @dredmorbius that’s not complicated, you just need your clock to always go forward, and not trust the timestamps of foreign sources completely. vector clocks are when you need to shuffle event logs together from multiple homogenous systems that aren’t perfectly synced, and where event order really matters.
here’s my note on that.
(i might have added vector clock)
Oh the other thing I figured is it needs some way of expressing 'change over time to JSON-like field structure'.
Which I think means it either needs a 'not' operator, or a defined semantics for 'null/undefined'. Ideally, if your change is removing one key 10 levels deep from a million-key object, you don't have to repost all the other 999,999.
@natecull @dredmorbius the main insight i got from the event structure in datomic here is it doesn’t try and capture a whole object in one event object. it does a keypath, a value, and a transaction id. you can do a whole object as s transaction with one event for each key, or a single key update. it doesn’t seem so important at first glance, but this elegantly solves a lot of tricky logic problems.
@natecull @dredmorbius so the core constructs in fro are signals, which are generated by “sources”, (oscillators, time, random number) modified by “filters” (math operators) and then output to the user in “sinks”. (speakers, disolays) only filters are pure, sources are impure on input. sinks impure output.
@natecull @dredmorbius then, the interpreter simply runs the graph 60 times a second, passing parameters in, pulling return values out, parcelling them to new parameters. nothing is persisted between calls unless you go to a lot of effort. and it’s a live coding environment, the program runs while you edit it, so changes get instant feedback.
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!