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> I'll write one right now in xslt
<ELLIOTTCABLE> -didja didja @ prophile
<purr> prophile: didja didja didjaaaaaaaaaaaaaaa … writeapawsyet?
<prophile> didjaredoo?
<ELLIOTTCABLE> -how about now? @ prophile
<purr> prophile: well? didja didja?
<ELLIOTTCABLE> Paws.xslt
<ELLIOTTCABLE> oh gods >,<
<prophile> the parser spits out a paws AST in XML
<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]