<whitequark>
"public domain" concerns copyright. liability doesn't really play any role in that
<whitequark>
(also worth noting that "public domain" doesn't exist everywhere)
<gkatsev>
which is why I prefer the MIT license. It's supported in more places than public domain is.
<gkatsev>
and with that comment, I go sleep.
jesusabdullah has quit [Read error: Operation timed out]
<eligrey>
all of my stuff is MIT licensed
<eligrey>
except classlist.js
jesusabdullah has joined #elliottcable
eligrey has quit [Quit: Leaving]
<whitequark>
so this guy is a designing engineer
<whitequark>
right now his job requires him to, quote, mould a house for mice
<whitequark>
I don't even
<ELLIOTTCABLE>
hello
<ELLIOTTCABLE>
goodbye
glowcoil has quit [Remote host closed the connection]
<whitequark>
lolwhat?
<purr>
lolwhat
jesusabdullah has quit [Ping timeout: 255 seconds]
jesusabdullah has joined #elliottcable
glowcoil has joined #elliottcable
<glowcoil>
hy
<glowcoil>
ELLIOTTCABLE:
<glowcoil>
ya :\
sunline has quit [Remote host closed the connection]
sharkbot has quit [Remote host closed the connection]
sharkbot has joined #elliottcable
<purr>
<Benvie> cool thing is that es6 makes most templating engines obsolete
<glowcoil>
ELLIOTTCABLE:
<glowcoil>
ELLIOTTCABLE:
<glowcoil>
ELLIOTTCABLE:
<ELLIOTTCABLE>
glowcoil: hi
<ELLIOTTCABLE>
am coding almost kinda
<ELLIOTTCABLE>
sup
<ELLIOTTCABLE>
u dickface
<ELLIOTTCABLE>
glowcoil:
<ELLIOTTCABLE>
goddamnit
<ELLIOTTCABLE>
whitequark: hi!
<whitequark>
hi ELLIOTTCABLE
<ELLIOTTCABLE>
i'm trying to write code i am bad at it
<ELLIOTTCABLE>
but hey
<ELLIOTTCABLE>
would be cool to see some Paws code run, by a codebase, that isn't fucksane
<whitequark>
ELLIOTTCABLE: well
<whitequark>
Paws code or Wick code?
<whitequark>
I'm maybe not even opposed to former, I just like the latter much more ;p
<ELLIOTTCABLE>
Paws, lol.
<purr>
lol
<whitequark>
on the second thought your non-returning booleans disgust me to the very core of my existence
<whitequark>
I mean.
<whitequark>
go write me a not() function that works
<glowcoil>
oh man remember battlecollie
<ELLIOTTCABLE>
glowcoil: yes
<glowcoil>
<3
ELLIOTTCABLE is now known as BATTLECOLLIE
<BATTLECOLLIE>
you mean me
<glowcoil>
:DDD
<BATTLECOLLIE>
whitequark: if they don't work well, and I find myself to need a boolean type in the core of the language, I'll add one.
<whitequark>
BATTLECOLLIE: no, seriously
<whitequark>
how do you write a not() function with your booleans?
<whitequark>
as per your original proposal, i.e. me to write a pure Paws VM... what's the incentive?
* whitequark
shrugs
<purr>
¯\(º_o)/¯
<BATTLECOLLIE>
there is none;
<BATTLECOLLIE>
and if you like the ‘other parts’ of it enough to be inspired to write an awesome language that uses them, I'm all agog.
<BATTLECOLLIE>
seriously.
<BATTLECOLLIE>
All I want in the entire universe is to see the programming world made slightly less terrible by my efforts.
<BATTLECOLLIE>
I've known *forever* that the chance of Paws becoming a real, working product … much less a well-known language, much-much less one that makes anybody's life better,
<BATTLECOLLIE>
is miniscule.
<whitequark>
(other language) there's one thing I'm not doing ever again, and it is advocating my own language
<BATTLECOLLIE>
but the chances of somebody somewhere, in this room or elsewhere, being inspired by my ideas, or my talking about it, or my philosophy, to do something that benefits others?
<BATTLECOLLIE>
Mission accomplished, IMO.
<whitequark>
basically the entire purpose of Wick is to serve a proof of concept that it is a better Paws than Paws
<BATTLECOLLIE>
but, if you want an incentive:
<whitequark>
it doesn't exist outside of that, nor it ever will
<BATTLECOLLIE>
a language with two people working on it is (some huge multiplier)-times more likely to be successful, and to be something *other* than a waste of either of those peoples' time.
<BATTLECOLLIE>
and ditto three people vs two people,
<BATTLECOLLIE>
and so on, up to some level of diminishing returns.
<BATTLECOLLIE>
Or, to simplify: Working on a terrible Paws with me is more productive work, in the end, than working on an excellent Wick. ;)
<BATTLECOLLIE>
anyway:
<BATTLECOLLIE>
re not()'s
<BATTLECOLLIE>
A) dunno, would have to think about it. Busy elsewhere.
<BATTLECOLLIE>
B) doesn't matter, because ‘boolean’ is a misnomer.
<BATTLECOLLIE>
If I need a *true boolean*, I'll add one.
<BATTLECOLLIE>
For instance, there's a good chance that i'll add one to a later version of the spec, or at least use 'true' and 'false' labels or something, because of compare() existing.
<BATTLECOLLIE>
At the moment, conceptually *boolean* operations (compare, etc) using a ‘Paws' boolean’ is a bit of a hack. Possibly temporary, depends on if it pisses me (or others, e.g. you) off enough.
<BATTLECOLLIE>
But, that said, Paws' booleans *themselves*, that is, the concept of *literally not returning when no ‘result’ is relevant or generated*, is something I'm fairly dead-set on, unless it makes the language truly unwieldily to use.
<BATTLECOLLIE>
My opinion:
<BATTLECOLLIE>
things returning numeric 0, or undefined in JavaScript, or something like that, are mildly-harmless *bad habits* that encourage a *not at all harmless* bad habit: not fucking thinking about the return value of your API very much.
<whitequark>
I disagree, simply because "no result at all" is different from "the result of no"
<BATTLECOLLIE>
no, agreed.
<BATTLECOLLIE>
read above.
<BATTLECOLLIE>
“that is kind of a hack.”
<whitequark>
i.e. if you always return undefined, then you're right
<BATTLECOLLIE>
I'm speaking, here, of "no result at all." Paws' booleans in their *intended* form, not when they're being used to convey falseness.
<whitequark>
if nothing is returned, how do you sequence actions?
<BATTLECOLLIE>
what do you mean?
<whitequark>
say you want to execute a combination A returning nothing, and *after* it executes, combination B
<BATTLECOLLIE>
(going to go back to coding in a sec, mildly drunk, and really want to produce a little here. Not in the mood for in-depth chats, right this sec.)
<BATTLECOLLIE>
er, not sure on the *combination* level.
<BATTLECOLLIE>
but it's a simple, solved-problem at the routine level.
<whitequark>
how?
<BATTLECOLLIE>
As with everything else **ordering** is dictated by responsibility:
<whitequark>
plesae don't tell "locking".
<BATTLECOLLIE>
…
<BATTLECOLLIE>
why not?
<BATTLECOLLIE>
It's Paws. It's how it's designed. All ordering is managed by locking. That's the *purpose* of our locking system.
<whitequark>
no, your ordering is mainly managed by the executions
<BATTLECOLLIE>
It's so important I even wrote a note in my terrible spec: ‘This isn't just about concurrent-access; it's a system used for all sorts of purposes throughout the language.’
<whitequark>
ugh. fuck this.
<BATTLECOLLIE>
glowcoil: gone?
<glowcoil>
sorry was focusing on homework for a bit
<glowcoil>
BATTLECOLLIE: ordering is usually accomplished through *value-returning*
<glowcoil>
BATTLECOLLIE: *only* in the case of when there isn't a value do you use locking for ordering
<glowcoil>
BATTLECOLLIE: just because you *can* use locking for ordering doesn't mean it's a good idea
<whitequark>
the idea that the proper way to maintain ordering is to abuse the system used to represent ownership is abhorrent
<whitequark>
yes, exactly what glowcoil says
<BATTLECOLLIE>
ಠ_ಠ
<BATTLECOLLIE>
then I mis-named, or you mis-associated, responsibility as a whole.
<BATTLECOLLIE>
's a reason I'm not calling it locking.
<glowcoil>
BATTLECOLLIE: calling-back
<glowcoil>
BATTLECOLLIE: is how you sequence when a value is needed
<whitequark>
what glowcoil says
<glowcoil>
BATTLECOLLIE: responsibility is not involved
<BATTLECOLLIE>
only if you're being **synchronous**. And that's not true in a majority of situations.
<BATTLECOLLIE>
hence, you know, the entire point of Paws.
<glowcoil>
ddis
<glowcoil>
the point of paws is that
<BATTLECOLLIE>
yes, in the *single use-case* where you're called synchronously, and then you result synchronously, you're ordered by *the calling* itself*
<glowcoil>
you can write f(g)
<glowcoil>
where f gets suspended until g returns
<glowcoil>
and the *next line* or however you want to organize
<glowcoil>
gets executed regardless of g's or f's completion
<glowcoil>
like, the point of paws is specifying those relationships
<BATTLECOLLIE>
if A) your caller has other work to do, and doesn't stop its entire world to wait on you; or B) *you* have other work to do after trying to provide this particular result to the caller, then ordering is entirely in the domain of the responsibility system
<BATTLECOLLIE>
'n that's exactly what it's designed to handle.
<glowcoil>
remember stage()
<BATTLECOLLIE>
not-returning-a-value is one of the many special cases of those possibilities;
<BATTLECOLLIE>
and thus should be handled by the responsibility system.
<glowcoil>
although i think stage() as a primitive is Bad, and it should be possible syntactically
<whitequark>
BATTLECOLLIE: or, you know, you could not spuriously enforce synchronity *also in Executions*
<glowcoil>
but responsibility should *not* be necessary here
<BATTLECOLLIE>
whitequark: hm?
<glowcoil>
responsibility is for disparate things accessing the same resource
<whitequark>
there's *no* reason to enforce synchronity in executions, and the whole mess with locking being necessary to perform ordering stems from just that
<BATTLECOLLIE>
no, that's locking. and locking is a side-effect of responsibility.
<glowcoil>
BATTLECOLLIE: you should be able to write some code that says: do f. when f is done, do g. but while that's going on, do h.
<BATTLECOLLIE>
What you're seeing is the effect of the responsibility-system handling locking; *not* an effect of the locking-system handling responsibility.
<glowcoil>
BATTLECOLLIE: if you can write arbitrary dependency-trees, then that is possible
<BATTLECOLLIE>
glowcoil: you can; that kind of stuff is supposed to be handled by granular executions
<whitequark>
glowcoil: I don't care how you call it; what you have in the spec *is* a locking system
<whitequark>
er
<glowcoil>
BATTLECOLLIE: right and you do not need responsibility for this
<whitequark>
BATTLECOLLIE: ^
<BATTLECOLLIE>
… you can. by writing arbitrarily nested executions.
<glowcoil>
right so
<whitequark>
BATTLECOLLIE: it does all of locking and nothing more, therefore it is a locking system
<BATTLECOLLIE>
whitequark: yes, I'm aware. But I'm saying *that locking system* was *not designed for locking*. It happens to walk like a locking system, and quack like a locking system, *but it's an ordering system*.
<BATTLECOLLIE>
Yes, it damn-well does more, it fucking orders
<BATTLECOLLIE>
you just don't *like* that it orders.
<BATTLECOLLIE>
i'm going back to code.
<BATTLECOLLIE>
I'm too drunk for this argument right now.
<glowcoil>
BATTLECOLLIE: it orders in an entirely different fucking way
<glowcoil>
BATTLECOLLIE: ok we can continue talking later but you are confusing two entirely different things
<whitequark>
BATTLECOLLIE: yes, exactly
<glowcoil>
very specific order-recipes from the programmer
<glowcoil>
and ordering based on competing for the same resource, not planned by the programmer but necessary to stop race conditions and inconsistent states
<BATTLECOLLIE>
long story short: I understand your reservations; but none of them are convincing *outside of actively using it*. If, *writing code in it* is literally obtuse and difficult and whatnot, yes, I'll clearly be changing how it works; but none of the arguments against it *in the absence of actual user-experience testing* make it sound like a bad thing.
<whitequark>
BATTLECOLLIE: you can have asynchronity as a tool, you can have it as philosophy, and you can run around and masturbate with it
<glowcoil>
BATTLECOLLIE: please illustrate
<glowcoil>
BATTLECOLLIE: please please illustrate how you use responsibility to order like, print a and then print b
<glowcoil>
not necessarily code-illustrate
<glowcoil>
just ideas-illustrate
<whitequark>
you *are* masturbating with it, and I'm tired of having arguments where the main argument is "because asynchronity!!1one"
<glowcoil>
like, how does responsibility even come into play there
<whitequark>
not participating in Paws anymore.
<BATTLECOLLIE>
glowcoil: I didn't say it does *all* ordering.
<BATTLECOLLIE>
I'm saying, only, this:
<BATTLECOLLIE>
It was designed, from the very start, to do some of the ordering.
<glowcoil>
ugggggh i know that
<glowcoil>
i agree and like that
<glowcoil>
what i'm saying is
<glowcoil>
does print ever return
<BATTLECOLLIE>
so the argument “You're conflating your locking system to do the ordering!??! GET A REAL ORDERING SYSTEM YOU DUMBTARD!”
<BATTLECOLLIE>
is in valid.
<BATTLECOLLIE>
because it *is* the real ordering system, for those situations.
<glowcoil>
uggggggggghhhhh
<glowcoil>
BATTLECOLLIE: does print return
<glowcoil>
when done
<BATTLECOLLIE>
undefined, there is no print. (Not being pedantic, I literally can't figure out what you're asking me)
<glowcoil>
BATTLECOLLIE: ok, take some side-effecting opreation with no useful valuers to give back to the caller
<BATTLECOLLIE>
I mean, give me a question of the form “given a print which doesn't re-stage,” or “given a print that re-stages,”
<glowcoil>
BATTLECOLLIE: does it just leave a synchronous-caller hanging forever, or does it resume them when done
<BATTLECOLLIE>
ah k
<BATTLECOLLIE>
Leaves it hanging, presumably, given the phrase ‘synchronous caller.’
<glowcoil>
ok so
<glowcoil>
why is that sensible, when
<glowcoil>
if that side-effecting opreation *does* have a value ot give back
<glowcoil>
it *does* resume normally, with a value
<BATTLECOLLIE>
that's the sort of thing you convey in documentation. Invocation pattern being specific to a particular API chunk, the caller should know, and then use, the correct method
<glowcoil>
why not use the same system for sequencing in the cases where there's a value, or multiple values, or no valuse
<glowcoil>
like, this could be unified so you can use the same tools
<glowcoil>
or you use *entirely* different methods of programming paws depending on whether a method returns "ok done" or "ok done and also here's a message"
<glowcoil>
which is unnecessary, and bad design
<glowcoil>
responsibility is a great system, i like it
<glowcoil>
but use it for things that it is
<glowcoil>
and use resuming for things that that is
<BATTLECOLLIE>
last two sentences didn't make sense, rephrase?
<glowcoil>
like, so if A wants to jump to B, and then get a value back from B and then continue with that value
<glowcoil>
A calls B, and B resumes A with the value
<glowcoil>
but if A wants to jump to B, but B has no values to give back, but A wants to continue *after B is done*, just like in the previous situation
<BATTLECOLLIE>
no, *just* the last two messages; I get the rest
<glowcoil>
all of a sudden you use something entirely different?!
<glowcoil>
ok the last two messages
<glowcoil>
we have a good system for ordering
<glowcoil>
the dependency tree/calling-and-resuming/whatever
<glowcoil>
that is for *intentional ordering*
<BATTLECOLLIE>
the problem is in *thinking* about everything like that, as if the B in the first message and the B in the second message are the same thing.
<BATTLECOLLIE>
Look at it this way:
<glowcoil>
they ARE the same FUCKING thing
<BATTLECOLLIE>
you're basically saying,
<BATTLECOLLIE>
“So, if A wants to call function B, …”
<BATTLECOLLIE>
and then “So, if A wants to throw exception B, …”
<glowcoil>
what?!
<glowcoil>
not in any way whatsoever
<BATTLECOLLIE>
and then yelling at me for those two things having different syntax or different patterns-of-use.
<glowcoil>
how is
<glowcoil>
printing
<glowcoil>
throwing an exception?
<glowcoil>
that's complete nonsense
<glowcoil>
how is closing a port throwing an exception?
<glowcoil>
how is drawing to a screen throwing an exception?
<glowcoil>
there are plenty of things that have nothing to say back except for that they are done
<BATTLECOLLIE>
A bit of code that *never returns* is substantially different from a multi-entry coproducing tool, is substantially different than a synchronous mutate-and-return ‘function’, is substantially different from …
<BATTLECOLLIE>
blahblahblah.
<glowcoil>
and they are *not* exceptions, they're the same code-pattern as tasks that have something to say back when they're done
<BATTLECOLLIE>
executions are **a primitive**, in an *intermediate-form* language.
cloudhead has joined #elliottcable
<BATTLECOLLIE>
Something that they can be made to do via abstraction on top of existing tools, is something I have a hard time believing I should build into the language.
<glowcoil>
BATTLECOLLIE: you don't have to build it into the language
<glowcoil>
BATTLECOLLIE: this is a library choice
<glowcoil>
BATTLECOLLIE: both are entirely possible given the tools we have designed into the langauge
<BATTLECOLLIE>
so, again: I'm not sure why we're arguing it. Like I said: I'm *open to change*. I've heard your arguments, and all. Give me a chance to *use both solutions* while writing code, because I'm not actually *changing* it until I do.
<glowcoil>
BATTLECOLLIE: and you're saying, every standard library function that doesn't have values to return just *shouldn't return*, indistinguishably from an infinite loop
<glowcoil>
and then here comes this unrelated langauge feature we can make suck its own dick
<glowcoil>
to use for this purpose as well
<glowcoil>
ok so you have two routines, print something out and get a line of input
<glowcoil>
so getting a line of input uses normal returning, no responsibility necessary
<BATTLECOLLIE>
The language is basically stable. I'm not going to make any changes that don't *fix an actual design-bug*, until we start on the next big chunk. By which I mean, if it doesn't make something that's impossible, possible; or make something that's *obviously painfully obtuse* more sleek and friendly-UX, it's going to be put off.
<glowcoil>
printing something out *could* use normal returning
<glowcoil>
but instead oh we're going to use responsibility
<glowcoil>
BATTLECOLLIE: this is NOT ADDING A LANGUAGE FEATURE.
<BATTLECOLLIE>
yes, so it's even *more* trivial-why-are-we-arguing-this.
<BATTLECOLLIE>
It's something that could *literally* easily be changed at the last moment, as opposed to something difficult-to-change, but premature-to-change-right-now.
<BATTLECOLLIE>
/=
<BATTLECOLLIE>
Okay. *breathes*
<BATTLECOLLIE>
here's a more cogent example.
<glowcoil>
if you explained the tools paws gives you
<glowcoil>
then no one would naturally come up with your solution
<glowcoil>
like, resuming is obviously for resuming
<glowcoil>
and responsibility is not obviously for resuming, it's for atomicity and shit
<BATTLECOLLIE>
Was trying to figure out how to get into the details of this, but it's really not worth it, so,
<BATTLECOLLIE>
at a high level:
<BATTLECOLLIE>
*Lots of things* in *lots of languages* provide different calling-patterns for fairly similar things; some of them, with more back-flips than others. Many of those *could* be more integrated, but aren't (usually, because it's not worth it; for me, this one's for different reasons, but …).
<BATTLECOLLIE>
The *closest* example I can think of for this,
<BATTLECOLLIE>
is “multiple return-values.”
<BATTLECOLLIE>
(relevant, I'll get there in a sec)
<BATTLECOLLIE>
you *could* have something like lisp's literally-returning-multiple-values-to-a-single-place,
<BATTLECOLLIE>
but most languages have the user construct the pair or triplet of values, or whatever is relevant, into an array or set or something, and then return that.
<BATTLECOLLIE>
the caller, then, has to deconstruct those into individual variables within its own scope.
<BATTLECOLLIE>
Some languages even provide syntax / semantics for that exact situation.
<BATTLECOLLIE>
with Paws, yes, there's a little more syntax to it, but preparing-to-call-something-that-doesn't-return needing its own little backflips *isn't conceptually different* from preparing-to-call-something-that-returns-multiple-results in some other language.
<BATTLECOLLIE>
now, that's not a complete refutal to your argument: that's *just* preempting the response that ‘WHY are they treated differently, everything should be the same!’
<BATTLECOLLIE>
a *non-producing bit of code* is substantially-enough different, that it doesn't bother me that the use pattern is slightly different.
<BATTLECOLLIE>
as for the conceptual argument, I simply disagree. I mean, I'm not sure how to *argue* that, because I invented this thing in my head, and I simply clearly think about the entire architecture differently from how you do. To me, this is “the way it's always been”, and <clearly> makes sense and is the way it should be, for some value of <clearly.>
<BATTLECOLLIE>
and the only way to resolve that particular aspect, is to *work with it*. See which has the best actual usability-affecting patterns in active use.
<glowcoil>
there was a time before responsibility was even in paws, i thought
<BATTLECOLLIE>
yah, and this was completely undefined.
<BATTLECOLLIE>
but when responsibility ‘came in,’ it was definitely not a locking system.
<glowcoil>
like, returning null or the equivalent was the solution
<BATTLECOLLIE>
that came *after* it was originally conceived as necessary, waybackwhen
<glowcoil>
i know for a *fact*
<BATTLECOLLIE>
yeah, there was a lot of ‘nothingness’ concepts, all of which I've given up on including
<BATTLECOLLIE>
(got deferred to userspace, just like booleans, for now)
<glowcoil>
that responsibliity was not conceived to let you resume after something doesn't return
<BATTLECOLLIE>
conceived as a whole, for that? lol no. conceived in part, though? absolutely!
<purr>
lol
<BATTLECOLLIE>
do you want to keep talking about this? we're clearly getting nowhere. I've spent the last *hour* talking in here. /=
<glowcoil>
no i have to do homework
<glowcoil>
your position absolutely boggles my mind, and has convinced whitequark to stop being involved with paws
<glowcoil>
but yeah we're not getting anywhere
<glowcoil>
and i need to get some things done
<BATTLECOLLIE>
Frankly, it was far from the most likely thing to drive him away. He's, uh, fiery; and I'm very opinionated and stalwart.
<BATTLECOLLIE>
Neither is he dumb, literally the first thing he said when he decided to participate was “99.9% chance I'll want you to change something, you won't, and I'll ragequit.” :P
<glowcoil>
BATTLECOLLIE: regarding returning tuples, if you're returning multiple heterogenous values you should not be using multiple returns, you should be using tuples or whatever
<glowcoil>
BATTLECOLLIE: like there can be a more first-class system for it than in most languages but
<glowcoil>
BATTLECOLLIE: multiple returns is for homogenous sequences of values, since they go to the same syntactic place in the code
<BATTLECOLLIE>
yah, not disagreed. was besides my point
<glowcoil>
and in that case then no-returns means
<glowcoil>
an empty sequence
<glowcoil>
and thus should *not* return
<glowcoil>
but in the case of things that *finish* but have no values
<glowcoil>
that should not be semantically the same as something that has 0 values to return
<BATTLECOLLIE>
holy crap, squat toilets are a thing
<BATTLECOLLIE>
a really, really common thing
<BATTLECOLLIE>
I mean, you assume life is different in other parts of the world, but I never thought *this* different