<glowcoil>
vil: might have sampled that actually, or something
<glowcoil>
so I'm naming my hard drives after AIs
<glowcoil>
so far I just have HAL
<glowcoil>
going to have Wintermute, Samantha, Siri, etc.
perrier has quit [Remote host closed the connection]
perrier has joined #elliottcable
<joelteon>
nvm mail.app doesn't do that
<joelteon>
but it does uh
<joelteon>
have an archive shortcut
<alexgordon>
hi glowcoil
<alexgordon>
glowcoil: wondering if it would be good to have a cps operator
<alexgordon>
e.g.
<alexgordon>
A => B
<alexgordon>
means
<alexgordon>
A, (B -> Void) -> Void
<alexgordon>
but then I started thinking about external and internal cps
<alexgordon>
i.e. is it the caller's responsibility, or the function's?
<alexgordon>
you see this all the time in node
<alexgordon>
stat() and statSync()
<alexgordon>
it's ugly imo
<alexgordon>
on the other side you have callback (node) and inline (C#) styles of callbacks
<alexgordon>
it's a bit of a mess really
<alexgordon>
there's also the problem of over-parallelizing embarrassingly parallel problems
<alexgordon>
frequently you just need *one* layer of parallelism to saturate all your cores
<alexgordon>
doesn't help with concurrency though
prophile has quit [Quit: The Game]
<glowcoil>
alexgordon: like async blocks or w/e?
<alexgordon>
glowcoil: there's so many things it makes my head hurt
<alexgordon>
I'm going to write them all down so it makes sense
<alexgordon>
glowcoil: all of these concurrency mechanisms are related, loads of them can easily emulate other ones, but there's no one thing that does everything
<glowcoil>
ok
<glowcoil>
let me know what you come up with
<alexgordon>
it also interacts with iterators/generators
<alexgordon>
say you want to perform some parallel operations on all the lines of the file
<alexgordon>
the *fastest* way to do that would be to hmm, depends whether you're I/O bound or CPU bound
<alexgordon>
if you're CPU bound (the operation you're performing is slower than reading the lines), then you're better off performing each operation async
<alexgordon>
if you're IO bound, then the same I guess?
eligrey has joined #elliottcable
<glowcoil>
alexgordon: yeah the point of async is it works better for both cases, since it just lets whatever's ready to happen next happen
<glowcoil>
alexgordon: the reason *not* to use async is because it wrecks your program structure
<glowcoil>
alexgordon: but if it's easy and everywhere then there's no reason not to, right?
<alexgordon>
lol
<purr>
lol
<alexgordon>
glowcoil: the real problem with all of this is figuring out how to make it gel with the rest of a program
<glowcoil>
alexgordon: i feel like you can have a way to make async not be ugly and hard special cases
<glowcoil>
alexgordon: that's the idea of paws/hands
<glowcoil>
and reactive things in general
<alexgordon>
you're right async kind of ruins the whole point of a _function_, which is to isolate a certain bit of functionality
<glowcoil>
not really
<alexgordon>
yes really
<glowcoil>
you just change your notion of function
<glowcoil>
slightly
<glowcoil>
ok explain
<alexgordon>
open file, read lines, process lines, return from function
<alexgordon>
would be the traditional sequential way of doing it
<alexgordon>
and I like that, it's easy to get my head around
<glowcoil>
well in something that makes async natural
<glowcoil>
it looks like that except for the "return from function" part
<alexgordon>
...that function has certain performance characteristics
<alexgordon>
i.e. it's slow, but it's a slowness that is easy to contemplate
<glowcoil>
i maintain that that's just experience
<alexgordon>
my experience matters :P
* glowcoil
sighs
<glowcoil>
it's not even that hard to become experienced with something else
<alexgordon>
we've got to make things which are suitable for the 99% of java programmers out there
<glowcoil>
meaningful change requires at least some effort
<glowcoil>
you can make it enticing but
<alexgordon>
people have wives and kids and stuff, they don't want to learn how to program again!
<glowcoil>
also what's "suitable for java programmers" si
<glowcoil>
alexgordon: why not have sync{} blocks, or seq{} blocks, or whatever
<glowcoil>
alexgordon: though in your example none are needed since
<glowcoil>
alexgordon: in hands, name-binding is used to determine dependency
<alexgordon>
glowcoil: I want to work at a higher lebel of abstration
<alexgordon>
level
<alexgordon>
sure you CAN just have sync blocks or seq blocks
<alexgordon>
but
<alexgordon>
that's what we have now (well, async blocks)
<glowcoil>
yeah i feel that a more concise version of sync blocks is the ideal
<glowcoil>
with SSA name-binding as well
<alexgordon>
but in that example I just think do notation works best
<glowcoil>
yeah but the problem is when you have it much deeper than that
<glowcoil>
and for things like iterating on an array
<alexgordon>
yah
<glowcoil>
having non-cps async by the default makes the much more complicated cases way easier
<devyn>
just do everything-is-a-future and resolve IO dependencies at compile time
<devyn>
and an operator for ordering or something
<joelteon>
whoops
<joelteon>
i just took down the production site
<devyn>
bravo
* devyn
clapso
<joelteon>
turns out mysqldump locks the tables unless you use --single-transaction
<devyn>
does it delay comitting any transactions while REPEATABLE READ locked?
<joelteon>
dunno what that is probably
<devyn>
ah I see, it just keeps a snapshot at the time of the start of REPEATABLE READ so the transaction kinda sits within its own time bubble while modifications move on