ELLIOTTCABLE changed the topic of #elliottcable to: a _better_ cult ˙ ͜ʟ˙ embrace, extend, extinguish.
yorick has quit [Remote host closed the connection]
eligrey has quit [Quit: Leaving]
<ELLIOTTCABLE>
devyn: no that's what i'm saying
Sorella has quit [Quit: Ex-Chat]
eligrey has joined #elliottcable
sharkbot has quit [Remote host closed the connection]
sharkbot has joined #elliottcable
devyn has quit [Read error: Connection reset by peer]
devyn has joined #elliottcable
<devyn>
ELLIOTTCABLE: okay then yeah
oldskirt has joined #elliottcable
oldskirt_ has quit [Ping timeout: 272 seconds]
oldskirt_ has joined #elliottcable
oldskirt_ has joined #elliottcable
oldskirt has quit [Ping timeout: 240 seconds]
eligrey has quit [Quit: Leaving]
prophile has joined #elliottcable
sammcd_ has joined #elliottcable
Rusky has quit [*.net *.split]
sammcd has quit [*.net *.split]
vigs has quit [*.net *.split]
inimino has quit [*.net *.split]
irclogger_com has quit [*.net *.split]
inimino has joined #elliottcable
vigs has joined #elliottcable
Rusky has joined #elliottcable
irclogger_com has joined #elliottcable
nuck has quit [Read error: Connection reset by peer]
nuck has joined #elliottcable
yorick has joined #elliottcable
Sgeo has quit [Read error: Connection reset by peer]
Sorella has joined #elliottcable
Sorella has joined #elliottcable
alexgord_ has joined #elliottcable
alexgord_ has quit [Quit: Computer has gone to sleep.]
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
trolling has joined #elliottcable
prophile has quit [Ping timeout: 260 seconds]
<ELLIOTTCABLE>
devyn: in terms of first-classing responsibility …
<ELLIOTTCABLE>
I'm more and more convinced that the way to do that is to get rid of responsibility entirely; fix the abstractability problems with tires-style dependency expression, and hybridize that with Paws.
prophile has joined #elliottcable
<ELLIOTTCABLE>
The more I think about it, the more I imagine it trivial to redesign the paws reactor to remove all implicit ordering, and to handle *explicit* ordering in the form of a dependency-graph-Script.
<ELLIOTTCABLE>
Well. "Trivial."
trolling has quit [Ping timeout: 250 seconds]
alexgordon has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
eligrey has joined #elliottcable
trolling has joined #elliottcable
eligrey has quit [Quit: Leaving]
prophile has quit [Ping timeout: 260 seconds]
eligrey has joined #elliottcable
ohhmaar has quit [Ping timeout: 240 seconds]
ohhmaar has joined #elliottcable
eligrey has quit [Quit: Leaving]
<devyn>
ELLIOTTCABLE: so, basically pushing for what Micah wanted :)
<devyn>
ELLIOTTCABLE: and yeah, reactor code isn't really a big deal to change
alexgordon has joined #elliottcable
vigs has quit [*.net *.split]
vigs has joined #elliottcable
eligrey has joined #elliottcable
sammcd_ is now known as sammcd
trolling has quit [Ping timeout: 245 seconds]
Sorella_ has joined #elliottcable
Sorella has quit [Ping timeout: 256 seconds]
Sorella_ is now known as Sorella
Sorella has quit [Changing host]
Sorella has joined #elliottcable
prophile has joined #elliottcable
Sorella has quit [Quit: Ex-Chat]
eligrey has quit [Quit: Leaving]
eligrey has joined #elliottcable
oldskirt has joined #elliottcable
oldskirt_ has quit [Ping timeout: 255 seconds]
<ELLIOTTCABLE>
devyn: the *rammifications* are the hard part.
<ELLIOTTCABLE>
the reactor changes are truly trivial.
<ELLIOTTCABLE>
at least, the changes to handle dependency-script *trivially* ,are trivial. :P
<ELLIOTTCABLE>
for Paws.js, it'd just be taking each resumption, and following all the dependency-links; staging the handler, same as current, for the single data-depender if there is one, and then staging all non-data-dependers that are now allowed.
<ELLIOTTCABLE>
the things that worry me:
<ELLIOTTCABLE>
I don't exactly see how one *abstracts* away the dependency shit.
<ELLIOTTCABLE>
basically, encoding the side-effect dependencies of some operations on object `foo`, inside `my.routine`, requires knowledge of the insides of `foo`.
<ELLIOTTCABLE>
a huge part of the point of the responsibility design is that it was *very* friendly to encapsulation. From *your* point of view, a given abstraction could be an atomic operation; whereas from *its* point of view, it has the control over the data it needs to preform multiple-sequential-operations (whether read or write)
<ELLIOTTCABLE>
so.
<prophile>
have you tried XML?
<ELLIOTTCABLE>
is Tires-style dependency management something for which we're suddenly declaring that API designers have to document/expose their internal dependency-related operations?
<ELLIOTTCABLE>
I mean, maybe that's the way to go. but I'm not sold on the usage-pattern / developer-experience of this.
* ELLIOTTCABLE
pats prophile
<ELLIOTTCABLE>
good boy, have a cookie
<ELLIOTTCABLE>
-cookie @ prophile
<purr>
prophile: +v means cookie
<ELLIOTTCABLE>
besides that original issue with Tires (dunno if I ever expressed that, but yeah that.), the more specific issues I have with trying to bring that in to Paws:
<prophile>
useless side discussion: XSLT is turing complete
<ELLIOTTCABLE>
I don't see with much clarity how routine-level explicit dependencies interact at a *larger scale.* Responsibility is artistically simple, and cleanly enables towers-of-abstraction in clear ways
<ELLIOTTCABLE>
hey prophile,
<ELLIOTTCABLE>
-didja @ prophile
<purr>
prophile: didja write a paws yet? didja? didja!?
<prophile>
then you translate that into your result
<devyn>
ELLIOTTCABLE: I believe it can be abstracted away. but we have to try it. I think what led to the current problem with the Paws design is, well, simply not enough writing of actual Paws code, and too much theoretical discussion
<devyn>
if we do it
<devyn>
and try it
<devyn>
and try abstracting it
<ELLIOTTCABLE>
eh, other way around
<ELLIOTTCABLE>
but that's where I am nonetheless, for different reasons
<ELLIOTTCABLE>
I want to see if using the current design *is* that bad, with regards to responsibility
<ELLIOTTCABLE>
may all be an irrelevant discussion.
<devyn>
yes
<devyn>
personally, a Tires-y design would be preferable, but I know I value efficiency a little more than you do ;)
<devyn>
namely I really just don't see any way to make responsibility very efficient
<devyn>
you have to scan an entire object graph for child nodes and then collapse that into a mask, and then we need to be able to release parts of that mask later (probably)
<devyn>
it's crazy
<devyn>
I like things that are usable and inherently optimizable, even if they're naively terribly inefficien
<devyn>
t*
prophile has quit [Ping timeout: 245 seconds]
Sgeo has joined #elliottcable
<ELLIOTTCABLE>
okay well I'm totally up for redesigning responsibility in the small
<ELLIOTTCABLE>
you forget that *changing the design* is a valid optimization at this stage of Paws' development :P
<ELLIOTTCABLE>
I *want* masks to be efficient.
<ELLIOTTCABLE>
They *shouldn't* be some graph-climbing-y monster.
<ELLIOTTCABLE>
if they are, they're a failure, and I'm going to throw that entire system away. |=
<ELLIOTTCABLE>
also, something can only own masks, not … super-chunks of masks, whatever that even means. You can own *just* a sub-section of a mask, but not *just* a super-section.
<ELLIOTTCABLE>
idk words
<ELLIOTTCABLE>
but you know what I mean I'm sure I probably mos interepreted you idk by
<devyn>
there's a more efficient way to store masks, probably, but that doesn't really help with the crawling
<devyn>
I actually don't see any way to make that work well :/
<devyn>
I'll think about it more but
<devyn>
yeah.
alexgord_ has joined #elliottcable
<devyn>
that's really why I haven't implemented it at all yet
<devyn>
it's hard
<devyn>
especially since in multithreaded code, acquiring more than one lock at a time is kinda dangerous
<devyn>
there would have to be communication between reactors to change the masks when things get updated and modified
<devyn>
and
<devyn>
I dunno
<devyn>
complicated
<devyn>
just doesn't seem realistically optimizable atm
<devyn>
I'm not sure what a better design would be
<devyn>
other than explicit ordering
<devyn>
Tires-y dependency graphs kinda fit rather well into modern CS research on communication and stuff
<devyn>
whereas Paws is kinda doing exactly what has been proving to be bad
<devyn>
the thing is, from a high-level perspective, you'd think, well, reactors can just do other things while operations are blocked waiting for data
<devyn>
but that process of actually figuring out what needs what has so much overhead it's not worth it, compared to the weight of the actual work done
<devyn>
kinda the same situation with reader-writer locks: you'd think that having multiple tasks able to read from something at a time and only one able to write would be a performance bonus
<devyn>
but the overhead of a lock like that makes it totally not worth it compared to how long the actual work takes, usually
<devyn>
and if the work is taking a long time and RWLocks are beneficial, then you're probably doing something wrong.
<ELLIOTTCABLE>
well, that's not remotely true for the kinds of things Paws is interested in.
<ELLIOTTCABLE>
you're conflating responsibility with ‘locks,’ basically.
<ELLIOTTCABLE>
they look like locks, sound like locks, and quack like locks,
Sorella has joined #elliottcable
Sorella has joined #elliottcable
<ELLIOTTCABLE>
but the similarity to locks is analogous to the similarities between concrete and quartz:
<ELLIOTTCABLE>
the time-scale over which they are useful / exist is just, completely and mind-bendingly different.
<ELLIOTTCABLE>
*locks*, exist to synchronous and ‘safe’-ify (in ways that are obscure and unclear to an average programmer, somebody who doesn't think about paralellization stuff all the time) over a period of microseconds.
<ELLIOTTCABLE>
while, as I've said before and gotten into the Internet equivalent of screaming arguments about, responsibility exists to *order* things, not make them safe; and more importantly to this discussion, it exists over time-scales of at *least* seconds, if not minutes or hours, depending on the exact usage.
<devyn>
perhaps that's one use, yes, but there's definitely a need for fine-grained atomicity
<devyn>
and responsibility is too expensive for that
<devyn>
and I totally get what you mean, for ordering over longer periods of time
<devyn>
responsibility would be great for that
<devyn>
hmm
<devyn>
ELLIOTTCABLE: if anything, I think Tires-y is actually still more natural. Tires inherently conveys a sense of "communication", and one could simply run something that depends on a value that's not ready yet. Futures.
<devyn>
ELLIOTTCABLE: so basically, go even higher level rather than attempted low level
<devyn>
:)
<devyn>
maybe I should just try this, theoretically, on paper, and see how abstractable it is
yorick has quit [Remote host closed the connection]