devyn changed the topic of #elliottcable to: length matching is better than intuitiveness
eligrey_ has joined #elliottcable
eligrey has quit [Ping timeout: 240 seconds]
yorick has quit [Remote host closed the connection]
alexgordon has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<abad1dea>
fucking FCK
abad1dea is now known as ELLIOTTCABLE
<ELLIOTTCABLE>
glowcoil: wake up, please please please
<ELLIOTTCABLE>
devyn: and you, perhaps, depending on your sleep schedule
<devyn>
hi
<purr>
devyn: hi!
<ELLIOTTCABLE>
Been brainsing "holes."
<ELLIOTTCABLE>
Or the unnamed problem that they nominall solved, more accurately.
<ELLIOTTCABLE>
-brainsing
<purr>
ELLIOTTCABLE: switch to Spotify. put on Rachmaninov. lean back in couch. fold hands behind head. stare at ceiling.
<ELLIOTTCABLE>
so,
<ELLIOTTCABLE>
basically,
<ELLIOTTCABLE>
nope. /=
<ELLIOTTCABLE>
which is disturbing, because i'd been dismissing the-problem-that-holes-nominally-solve, in my head, 'cuz I assumed we were most of the way to a solution on that one.
<ELLIOTTCABLE>
not. at. alllllll.
prophile has joined #elliottcable
eligrey_ has quit [Quit: Leaving]
<devyn>
I think Tires is the best alternative to the holes thing, but that's a totally different idea :p
<ELLIOTTCABLE>
welllllll, they're not super-super related
<ELLIOTTCABLE>
well kinda.
<ELLIOTTCABLE>
okay am home
<ELLIOTTCABLE>
can type now
<ELLIOTTCABLE>
so, so exhausted
<ELLIOTTCABLE>
have slept N hours, where N is very small
<ELLIOTTCABLE>
The Problem:
<ELLIOTTCABLE>
arbitrary interlopers can schedule a staging that steals an argument from a strictly-patterned coconsumption exchange
<glowcoil>
hi
<purr>
glowcoil: hi!
<ELLIOTTCABLE>
(or, more generally, some staging-patterns are "structured", and can negatively interact with one-another)
<ELLIOTTCABLE>
The Shape of the Solution:
<ELLIOTTCABLE>
"during" a "staging-pattern" of some arbitrary form, "lock" out participants from interlopers' other patterns (or individual stagings)
<ELLIOTTCABLE>
define:
<ELLIOTTCABLE>
during.
<ELLIOTTCABLE>
staging-pattern.
<ELLIOTTCABLE>
lock out.
<ELLIOTTCABLE>
so, originally, thought-process was: "Let's make ‘calls’ exclusive: when you *call* somebody, as opposed to doing explicit Paws-y staging backflips for some arbitrary purpose, give them a ‘shaped hole’ instead of the traditional promiscuous reference-to-current-execution.”
<ELLIOTTCABLE>
idea having been, reactor can then register that a hole exists, and then somehow prevent standard stagings from processing until that call is 'complete.'
<ELLIOTTCABLE>
I always assumed that would work, in some form. huge mistake.
<ELLIOTTCABLE>
issues with that:
<ELLIOTTCABLE>
first off, and possibly most importantly, although a bit nebulous … it only proposes to solve the Problem for *a single pattern* (ish.) Basically, whatever "call" pattern we bless with holesing.
<ELLIOTTCABLE>
second, and more concrete:
<ELLIOTTCABLE>
quick, somebody, try to show me how a coconsumptive parameterization pattern would play out, with holes?
<ELLIOTTCABLE>
(it doesn't. I spent half an hour today on that alone. /= )
<ELLIOTTCABLE>
holes, first, require knowledge of the 'caller' *and* 'callee' on the part of the hole itself, which breaks the desirable Paws behaviour of discarding the concept of a "caller" at all, and only caring about the return-point we're handed.
<ELLIOTTCABLE>
and second, holes work for **a single resumption-slot**. basically, they're continuations. How, exactly, does that work for *any* staging pattern (including simple coproductive parameterization) more complex than 'stage this foreign procedure with a single argument.'
<ELLIOTTCABLE>
third, and I didn't get to nail this one down before we arrived here at home where I can type; but I'm *pretty sure* holes require a new syntax; either that, or they're going to *hugely* bloat the code-overhead for a simple fucking procedure-call. Perhaps even to the point of making bootstrapping that with abstractions, impossible.
<devyn>
explain holes again?
<vigs>
A young Shia LeBouf (sp?) gets in trouble and is sent to a camp where everyone's forced to dig holes as punishment.
<vigs>
I just printed the contents of this array that I'm iterating through into the console and it prints three resources it gets from the API, then the three functions I added to Array ಠ_ಠ
<ELLIOTTCABLE>
show me a working Furrow interpreter, and tell me the syntax to type in to see that working :P
<ELLIOTTCABLE>
I didn't say I'd *seen it implemented*. Just that it wasn't a new idea.
<alexgordon>
ELLIOTTCABLE: :P
<ELLIOTTCABLE>
I've known I'm going to have it in Fullness for ages; and I'm fairly damn sure I'd heard of it somewhere else, first, too.
<alexgordon>
so
<alexgordon>
I built furrow today
<alexgordon>
(built as in compiled)
<alexgordon>
and... it compiles
<alexgordon>
how cool is that
<alexgordon>
was expecting a gazillion errors
<ELLIOTTCABLE>
what, have you never compiled it before? o_O
<alexgordon>
ELLIOTTCABLE: not for months
<alexgordon>
I'd been under the impression that it was totally broken
<alexgordon>
which is why I hadn't touched it
<alexgordon>
but apparently it was fine
<alexgordon>
spent some time today working on an AST program representation
<alexgordon>
and now I'm working on a DSL for the codegen stage
<alexgordon>
lots of the codegen code is quite mechanical. some bits will have to be special cased but hopefully the majority of it can be auto-generated
<alexgordon>
that's right, I'm code generating my codegen code
<ELLIOTTCABLE>
lololol
<purr>
lololol
<ELLIOTTCABLE>
I have no idea what most of this means.
<ELLIOTTCABLE>
i am bad progamer
<alexgordon>
ELLIOTTCABLE: you know a compiler right?
<ELLIOTTCABLE>
yep
<alexgordon>
ELLIOTTCABLE: the classical stages of a compiler are lexical analysis (regexes), syntax analysis (parsers), semantic analysis (errors/warnings/static types), code generation (generating asm/c/llvm ir)
<ELLIOTTCABLE>
Cheery: the core premise behind Paws is that we wanted a truly asynchronous language.
<ELLIOTTCABLE>
(since you're new here: I come from a rather staid / hipster history; lots of Ruby, JavaScript, a lot less Haskell, Lisp, or even-more-obscure shit like stack or logical languages)
<ELLIOTTCABLE>
(hence, Paws is very much a language with a slow, but very dynamic and expressive feel; and gives the user a lot more room to shoot themselves in the foot, without things like static typing, purity, or easy static analysis.)
<ELLIOTTCABLE>
(I hope that's not up your alley of language tastes.)
<ELLIOTTCABLE>
almost every language I've ever run across is inherently *synch*:
<ELLIOTTCABLE>
at worst, they're stack-based, and you *can't* ever do anything in 'procedure-call' (whatever form that may take) except preform some calculations, push other procedures (themselves necessarily synchronous) onto the stack, and then give up your control and “return” to some privileged caller up the stack.
<ELLIOTTCABLE>
sometimes, if you're lucky, that environment exists on top of some lower-level, opaque "event loop" that your synchronous operations can manipulate and leverage. that's really no solution, most of the time, though, introducing all sorts of conceptual overhead, and relegating you to some linguistic equivalent of callbacks.
<ELLIOTTCABLE>
a bit higher up the asynchronicity ladder, you've got truly stackless languages, in which things like coroutines (or at least pervasively available continuations) *let* a user, occasionally, do actually-asynchronous operations amongst their synch code.
<ELLIOTTCABLE>
the only places I've seen *real* pervasive asynchronicity are truly weird, obscure shit; things inaccessible to the “average programmer.”
<ELLIOTTCABLE>
(I've had this argument before, and don't want to again, so I'll just summarize my definition there, and leave it alone: “average programmers” write Java, C++, Obj-C, JavaScript, Ruby, Python, or another language like that. If you grok Haskell, a LISP, or even know what a declarative logic language *is*, you're no longer an ‘average programmer’ in my
<ELLIOTTCABLE>
book, and no longer of interest to me as a target-market.)
<ELLIOTTCABLE>
so.
<ELLIOTTCABLE>
I came out of that environment wanting the following:
<ELLIOTTCABLE>
a language that is asynchronous *always, everywhere* (i.e. any invocation of somebody else's code, inherently assumes that that somebody-else will be able to take *as long* doing *as many things* as they want, with no assumption of ‘returning’ immediately, or even ever.),
<ELLIOTTCABLE>
that is accessible to people coming from the completely procedural, ‘object-oriented,’ dynamic languages that are popular nowadays: JavaScript. Ruby.
<Cheery>
async dynamic language?
<ELLIOTTCABLE>
yep
<yorick>
y u no callcc
<ELLIOTTCABLE>
yorick: explicit.
<ELLIOTTCABLE>
this has to be *explicit*.
<Cheery>
doesn't sound much different to what I'm actually attempting to do myself.
<ELLIOTTCABLE>
If I write an abstraction that requires asynchronicity,
<ELLIOTTCABLE>
I don't want to restrict my abstraction to users who understand a little-used language feature.
<Cheery>
I realised yesterday I have to study julia language papers.
<ELLIOTTCABLE>
if *every single 'call'*, anywhere, of any sort, is asynchronous, then *asynchronous* abstractions won't be second-class to synchronous ones,
<ELLIOTTCABLE>
as they are,
<ELLIOTTCABLE>
absolutely,
<ELLIOTTCABLE>
fucking,
<ELLIOTTCABLE>
everywhere.
<ELLIOTTCABLE>
yorick: just sayin'.
<ELLIOTTCABLE>
okay. So, that's the “why” rationale.
<ELLIOTTCABLE>
lemme know if I'm getting too high-minded and you just want me to tell you bits of the code. :P
<ELLIOTTCABLE>
“what” rationale:
<ELLIOTTCABLE>
since i'm targetting people coming from very dynamic languages, friendliness to *abstraction* is a very core goal. I want something between Ruby and LISP, something enabling users, with ideas I didn't think of, to write unreasonably powerful abstractions that change the entire feel of the language for other users.
<ELLIOTTCABLE>
I discovered that that rabbit-hole goes *very* far down, very fast.
<ELLIOTTCABLE>
Paws kinda takes that as far as it can possibly go.
<ELLIOTTCABLE>
after much iteration, removing things from the language that we realized could be implemented in terms of *other* things, as abstractions, later on,
<Cheery>
I'm bit occupied at the moment :) it's like all the fucking stuff worth reading came out today, not yesterday when it'd have been useful.
<ELLIOTTCABLE>
(links!)
<ELLIOTTCABLE>
we've long since been at the point where Paws is basically an unusable-by-humans (hah.) virtual-machine for *other* languages in this family to target.
<vil>
I tried to learn it once and can attest to the "unusable-by-humans" part
<ELLIOTTCABLE>
vil: heh, it's better, nowadays.
<ELLIOTTCABLE>
vil: lol.
<vil>
I bet so
<vil>
that was quite some time ago
<ELLIOTTCABLE>
it's not unusuable in terms of concepts; it's just unusuable without first writing yourself (or using somebody else's) abstractions.
<Cheery>
yesterday were reading about algorithm (were trying to figure out a name for an algorithm)
<Cheery>
found garbage in garbage out, and first out never out.
<ELLIOTTCABLE>
Cheery: m'kay. I'm gonna work on specification-stuff over here, but let me know when you have some time, and I'll work you through the meat of it.
<Cheery>
were derailed a bit there.
<ELLIOTTCABLE>
vil: wish you knew it better, I need to talk through some though-work here.
<ELLIOTTCABLE>
hm, who's kaplan?
<vil>
ELLIOTTCABLE: someday I will finally have time to sit down and have you teach it all to me properly
<vil>
probably right about when you finish :D
<ELLIOTTCABLE>
won't take much time. :P
<ELLIOTTCABLE>
make an impl!
<ELLIOTTCABLE>
that'll explain it all.
<ELLIOTTCABLE>
it's truly trivial to create a non-parallel implementation.
<ELLIOTTCABLE>
I keep telling people that.
<vil>
which one is currently the best? I should go read it
<ELLIOTTCABLE>
the only non-trivial part is working around the terrible specification. >:
<ELLIOTTCABLE>
Paws.js is very, very simple code through-and-through.
<vil>
hehe
<vil>
k
<ELLIOTTCABLE>
Hell, I'm subjecting myself to fucking *CoffeeScript*, specifically in hopes that somebody like you will come along and read the source to understand it.
<vil>
D:
<ELLIOTTCABLE>
the meta-code documentation (i.e. comments and shit) are lacking,
<vil>
I am so sorry
<ELLIOTTCABLE>
but it's very self-documenting code. Or it should be.
<vil>
alright, I will attempt to do that soon
<ELLIOTTCABLE>
If any of it's *not* (except perhaps advance(), which is a straight-up clusterfuck and getting thrown away some day), well, tell me, so I can refactor.
alexgordon has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
eligrey has joined #elliottcable
prophile has quit [Quit: The Game]
<devyn>
ELLIOTTCABLE: yo, solution me
alexgordon has joined #elliottcable
alexgordon is now known as motherbitches
motherbitches has quit [Disconnected by services]
alexgordon has joined #elliottcable
<alexgordon>
mmmm
<alexgordon>
this sucks :|
<alexgordon>
type systems!
<joelteon>
like a keyboard?
<joelteon>
hey guys, what's your favorite cherry mx switch?
<gkatsev>
a coworker just got a keyboard made with entirely cherry mx clear
<joelteon>
how is it?
<joelteon>
those are the stiff tactile, right?
<gkatsev>
yeah, they're stiffer than the browns
<gkatsev>
he has a brown right next to it
<gkatsev>
it's interesting.
<gkatsev>
it feels like you can type better with less mistakes because it requires more energy to depress but also you can more readily stop yourself from typing a key
<gkatsev>
also, it feels like you can move onto writing the next char earlier
<gkatsev>
but I haven't used it extensively
<joelteon>
have you used blues?
<gkatsev>
I don't think so
<joelteon>
ok
<joelteon>
I love blues but my coworkers don't
<gkatsev>
the clears also end up being quieter than the browns
<gkatsev>
this coworker has around $900 worth of keyboards around his desk right now
<joelteon>
think I might go with clears then
<vil>
joelteon: I've repeatedly heard that clears are the best
<joelteon>
:U
<joelteon>
maybe i'll go with those then
<vil>
they're also typically more difficult to get ahold of
<joelteon>
yeah, that won't be a problem
<joelteon>
my plan is planned
<alexgordon>
joelteon: lol no not like a keyboard
<purr>
lol
<joelteon>
i know
<joelteon>
i was making a joke because i was thinking about my keyboard
<alexgordon>
joelteon: I know
Sgeo has joined #elliottcable
oldskirt has quit [Quit: gone]
<joelteon>
i gotta try clears out before i buy
<joelteon>
i don't know whether they'll take too much force to use
<gkatsev>
clears are supposed to be better?
<gkatsev>
my coworker is thinking of returning that keyboard, actually
<joelteon>
that's what vil just said
<joelteon>
that's my source
<gkatsev>
I didn't know whether they were supposed to be better or not and that my coworker is thinking of returning the keyboard with the clear keys
<joelteon>
i have browns right now but i don't know if i like them
<joelteon>
maybe i'll put o-rings on them to stop bottoming out
yorick has quit [Remote host closed the connection]
<ELLIOTTCABLE>
… does nobody make high-budget keyboards like this with *low* keys?
<ELLIOTTCABLE>
I fucking hate IBM M-style high-ass keys.
<ELLIOTTCABLE>
worst to type on.
<ELLIOTTCABLE>
I gave my Das Keyboard to, uhh, I think nexxy, because of that.
<joelteon>
well the keycap has to cover the switch
<joelteon>
i suppose you could get a keyboard with low keycaps but it would have to be really thick
<ELLIOTTCABLE>
not with these switche
<joelteon>
right
<joelteon>
well
<ELLIOTTCABLE>
these are obviously built for tall keycaps
<joelteon>
good luck
<ELLIOTTCABLE>
I just mean, Apple-like keyboards from a third party
<joelteon>
dunno man
<joelteon>
maybe you could spearhead that effort
<devyn>
frankly I really like both
<joelteon>
yeah, i'm leaning toward reds
<devyn>
but typing on tall keycaps with browns is just so much more… satisfying
<joelteon>
they're so nice
<joelteon>
the brown doesn't have enough of a tactile bump
<joelteon>
i want either no bump or lotsa bump
<devyn>
haha
<joelteon>
i'm pretty sure the noise from the blue is influencing me
<joelteon>
a silent blue would be something different
<joelteon>
silent blue aka clear
<devyn>
nah a clear isn't a silent blue
<devyn>
the click of the blue isn't purely audible, you can feel it too
<joelteon>
i know
<devyn>
solely*
<devyn>
and clears are also stiffer
<joelteon>
it's like a "pop"
<joelteon>
brown is like a "thunk"
<devyn>
the tactile bump on the browns and the blues is identical, it's just that blues have the click too
<joelteon>
no way
<joelteon>
wow maybe it is
<joelteon>
i have a switch tester
<devyn>
they have the same actuation force and the shape of the little bump inside is the same
<joelteon>
it just arrived this morning
<joelteon>
it's a lot of fun
<joelteon>
brown is just blue without the white thing i guess
<devyn>
yep
<joelteon>
yeah i think it's gotta be red
<joelteon>
no i think they're slightly different because you can also feel the clicking of the thing
<joelteon>
talk about bikesheds though
<joelteon>
holy shit
<ELLIOTTCABLE>
wow.
<joelteon>
it matters ec it matters
<ELLIOTTCABLE>
devyn: my solution wasn't very good.
<ELLIOTTCABLE>
devyn: basically was thinking about making [] return a "hole", and passing that hole to something as a resumption-vaue activated it, and made the thing passed-to the only thing able to resume you
<ELLIOTTCABLE>
and then having a library function to free that up
<ELLIOTTCABLE>
solves coproduction.
<ELLIOTTCABLE>
foo[][a][b][c]
<ELLIOTTCABLE>
can't be interloped
<ELLIOTTCABLE>
but meh. a mess for anything else and ruins the good-parts of coproduction
<ELLIOTTCABLE>
honestly, not convinced anymore that it's a problem
<ELLIOTTCABLE>
another thing that's starting to look like it can be solved by abstraction.
<ELLIOTTCABLE>
maybe what we *really* need is a better way to abstract over responsibility-like concepts.
<ELLIOTTCABLE>
this stuff should be buildable libside.