meowrobot has quit [Quit: let us connect our intestines and mutually digest]
meowrobot has joined #elliottcable
<pikajude>
apple software is all bad
<ljharb>
lol
<purr>
lol
alexgordon has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Rurik has quit [Ping timeout: 272 seconds]
eligrey has quit [Quit: Leaving]
<ec>
alexgordon: am now
<ec>
wtf cores, wtf tho
<ec>
ja: I'm a terrible programmer, but I happen to be rather ridiculously knowledgeable about regular-expressions and git
<ec>
plz don't come to me for programming advice; but feel free to use me as an interactive reference document for either of those :P
<ec>
ugh wtf CoreOS
<ec>
every container I keep trying fails with some error relating to the arguments `exec` takes; and CoreOS has no `man` utility, nor can I find any manpages for its shipped binaries / builtins *anywhere*
Rurik has joined #elliottcable
meowrobot has quit [Quit: let us connect our intestines and mutually digest]
meowrobot has joined #elliottcable
<ec>
oh wow as of iOS 9, the menubar RSSI can be tapped to toggle with normal ‘bars’
<ec>
I don't have to reboot my phone if I forget which dBM converts to which strength!
Rurik has quit [Ping timeout: 255 seconds]
Rurik has joined #elliottcable
<ec>
my Mac Pro is fukt
Hrorek has joined #elliottcable
alexgordon has joined #elliottcable
Rurik has quit [Ping timeout: 256 seconds]
perrier__ has quit [Remote host closed the connection]
perrier has joined #elliottcable
<ec>
asciinema is really cool
alexgordon has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<alexgordon>
ec: I had a programmy language idea, but then I thought, "why am I asking ec, he doesn't do conventional stuff"
<ec>
lololol
<purr>
lololol
<ec>
meaning what?
<alexgordon>
ever heard of paws?
<alexgordon>
we need some more young blood in here
<ec>
yep
<ec>
and Paws isn't the be-all-end-all of my language interest :P
<ec>
I love lisp, I love ES6 and the ‘fixing’ of JavaScript in general, and I'm very interested in Nim
<ec>
& rust
<ec>
Paws is only important because of an idea within it; something I've somehow failed to explain to anybody except micah
<ec>
the rest of Paws is just … incidentals. implementation detail. lol cruft.
<purr>
lol
<alexgordon>
ec: nim is pretty conventional
<alexgordon>
are you sure?
<mkroman>
how's Paws different from OTP?
<alexgordon>
erlang?
<alexgordon>
um
<alexgordon>
man
<alexgordon>
how is prolog different from coffeescript
<alexgordon>
it just is
<ec>
yeah, not sure what it's got to do with erlang
<alexgordon>
mkroman: paws is a bit like urbit
<mkroman>
I see
<alexgordon>
but harder to understand
<ec>
erlang belongs to the category of ‘Let's Solve Parallelism and Concurrency’ projects where they basically allow you to work in a *non*-parallel mindset most of the time, and then very carefully and specifically define where/how those sequential/non-parallel blocks interact in parallel
<ec>
(not that I think that's necessarily the *wrong* approach)
<ec>
(it's just the form that *almost* every currently-popular approach takes, and thus not an style i'm interested in trying to rehash myself)
<ec>
Paws belongs to the *completely different* category of trying to solve those problems *without* discarding the expressive power of shared-memory / OOB-communication (which is the massive downside of most of the solutions in aforementioned Erlang-ish category)
<ec>
lol urbit
<purr>
lol
<ec>
yeah basically
<ec>
who's mkroman, again?
<ec>
mkroman: Paws doesn't exist, mind ye it not *waves hands dismissively*
<ec>
oh wait, is that ja's friend?
<mkroman>
I'm a friend of ja's :p
<ec>
ahhh yes
<alexgordon>
who is ja again?
<ec>
well, welcome to the channel
<mkroman>
thanks
<ec>
mkroman: I thought you were somebody else.
<ec>
mkroman: I'm happy to talk about Paws with you, if you'd like; I thought you already knew what it was, and were making a joke. :P
<ec>
wasn't kidding, though, it's a dead project. Literally of interest only to me, or for esoterica.
* ec
pats alexgordon
<alexgordon>
yeah micah going to university really killed it :P
<alexgordon>
cause he was the only person who understood it enough, and could explain it to others
<mkroman>
oh, no – I just read a paragraph and thought it sounded a lot like using the erlang VM (i.e. erlang/elixir/…) and OTP
<alexgordon>
bus factor 1
<ec>
man, I love ruffles
<ec>
alexgordon: Don't think Micah killed it; think it being a terribly slow language killed it
<alexgordon>
that too
<ec>
it's almost certainly unoptimizable in *my* design
<ec>
the only issue I have, is that there *are* some really fucking cool elements in that design; I really had hoped that my terrible, slow, hodgepodge of a programming language could bring those ideas to the right eyes to have them imitated by other, better, languages. /=
<alexgordon>
like what?
<ec>
I'm so going to cry on my deathbed if I never see a language implement Paws' ordering approach to concurrency, for instance
<alexgordon>
ok I am never going to understand that
* ec
¯\_(ツ)_/¯
<ec>
I swear to heaven it's really not complicated
<ec>
glowcoil going “guys, it's really not that complicated” every five minutes for two years wasn't a joke :P
<alexgordon>
yeah you know the other thing that killed it?
<alexgordon>
changing the whole spec every month
<ec>
there *was* no spec because it wasn't remotely *done* :P
<ec>
me asking other people to implement it was a mistake, though.
<ec>
that was basically an X/Y problem writ large
<ec>
What I said I wanted: ‘Implement Paws!’
<alexgordon>
I dunno, if you'd had one version and had just decided "this is it"
<alexgordon>
then I could have made a prototype
<ec>
What I actually wanted: ‘Care about Paws enough to pay attention to the small, fiddly details, so you can tell me if I'm getting them wrong!’
<alexgordon>
but I felt what's the point, because it would just be invalid next month
<ec>
I just never really knew how to communicate that, or convince anybody to do that if they weren't invested because they'd put effort into a codebase.
<alexgordon>
kind of like node.js trolololol (seriously, version 5?)
<purr>
trolololol
<ec>
but yeah, it'd have been foolish to put much effort into implementation when it was so in flux
<alexgordon>
ec: so my idea last night was this: what if you had a programming language anybody could edit
<alexgordon>
like... a crowdsourced language
<ec>
that's already kind of a thing
<mkroman>
you'd end up with a bunch of dickbutts
<ec>
two approaches:
<alexgordon>
mkroman :D
<ec>
1. there's a language that refuses to add any feature before *science* proves it's a good idea
<alexgordon>
that sounds boring
<ec>
by their definition, that means they fund a rigorous sociological study on every single proposed feature
<alexgordon>
I saw that one
<ec>
yeah, it's boring and terrible and a huge failure
<alexgordon>
actually, it sucks
<ec>
but it's in that vein
<ec>
and 2. Paws ;)
<alexgordon>
:D
<alexgordon>
no, I was thinking more
<alexgordon>
there was a github project
<ec>
that's, like, one of the three big things that disappoint me in Paws being a failure
<alexgordon>
where anybody could submit a pull request, and it would be voted in
<alexgordon>
*on
<ec>
that, not any weird performance bullshit, is why I cared about microkernel / dynamic-syntax languages
<ec>
I wanted to see what sorts of *communities* evolved around a language where you picked what features you wanted,
<alexgordon>
ec: well, why not try it
<ec>
where consensus could be reached about *syntax* and *core semantics* as easily as it could be on *idioms*
<alexgordon>
but with a more sensible design :P
<alexgordon>
a real compiler
<ec>
basically because I can't give up any of the cool ideas /=
<ec>
Paws is something like three to five individually-excellent ideas, that I care about all of equally much,
<ec>
and I can't bring myself to give up on four of them to build a *viable* product on on of them.
<alexgordon>
ec: I think the idea of an evolving language is a good one (because I came up with it so it must be)
<ec>
hence: “I'll be super-depressed if *none* of these reaches the light-of-day, because I was too busy trying to make *all* of them do so.”
<alexgordon>
ec: but it has to be practical otherwise nobody will care
<alexgordon>
I am going to make a prototype
* ec
nods
<ec>
I think voting is the wrong way to do it
<alexgordon>
yes
<ec>
best if there's no central / canonical authority *at all*
<alexgordon>
like wikipedia
<alexgordon>
if something gets too hot you can lock it
<alexgordon>
to more experienced people
<ec>
take the Paws approach, if you do this: “Anything goes; and build your own community around your opinion of ‘<this particular thing> should *not* go.’”
<alexgordon>
ec: you seen that famous erlang mailing list message about a flat module system?
<ec>
works great for FOSS in general, in the large; works especially great for FOSS libraries, when you have a powerful package-manager and package-repository (like npm or ruby gems)
<ec>
so make it work for language features too
<ec>
no, haven't, tell me more
<alexgordon>
ec: ^ I've been doing some work on that, I'll tell you later
<ec>
yeah, that's pretty similar to some of my thoughts
<ec>
but instead of flattening it, it's *exploding* the structure
<ec>
i.e. don't do away with Module™ that holds foo and bar,
<ec>
but guarantee that foo and bar are both 1. accessible sans Module, 2. usable sans Module, and 3. individually replaceable even if *using* Module.
<ec>
so that the hierarchy becomes a hinting system, a set of more and more specific suggestions of “what to use <thing> with.”
<ec>
but at the core, all chunks of implementation are granular, and available at the tightest-scoped level
<ec>
make sense?
<ec>
that's Paws' approach, basically.
<alexgordon>
ec: yes
<ec>
tell me more later.
<ec>
relationship things melting down.
<alexgordon>
uh oh
<ec>
as usual. #elliottlyfe
<ec>
brb
<alexgordon>
ok. prototyping
<ec>
lol
<purr>
lol
<ec>
I'll give you that:
<ec>
you dive right in.
<ec>
sometimes, without much thought. ;)
<ec>
(says the dude who's put *five years* of thought into his Omega Project. >,>)
<ec>
(i.e. don't take my advice <,<)
<alexgordon>
:D
<alexgordon>
only way to try is to make!
<alexgordon>
plus I've been doing so much web dev recently that I don't even have to think
<alexgordon>
total autopilot
<ec>
npm is basically this.
<ec>
tons of people commit single-function ‘modules’ to npm nowadays; and that's officially sanctioned by the npm people as Kind Of The Purpose Thereof.
<ec>
you commit modules composing other modules, which also covers how I described Paws' approach.
<ec>
npm *itself*, as of the most recent version, is an excellent example: it's split up into a bunch of individually-installable modules, that themselves compose functionality from a bunch of single-purpose third-party modules, with very little business logic themselves
<ec>
the only *real* difference here, would be *disallowing* the compositions from having additional logic.
<ec>
i.e., a node can only be *either* A) functionality, or B) composition of other nodes
<alexgordon>
yeah
<ec>
instead of allowing modules that primarily compose other modules to add their own functionality
<ec>
ooo this is a good idea, I like it, I'm keeping it
<ec>
namely, how hugely fucking much semver sucks colossal stallion testes
<ljharb>
semver is wonderful.
<ec>
Versioning is a Terrible Way To Program
<ec>
ljharb: don't even
<alexgordon>
ec: I have ideas in that department
<ec>
cannot have this discussion with a Deep Node'er
<ljharb>
lol
<purr>
lol
<ljharb>
k
<ec>
ironically, I've had the *best* discussions about this topic at JSconf(s)
<ec>
but always with fringe JavaScripters … those *just enough* infected with the New Npm Way to see the light I see, but not enough so to shut down discussion of how much current-npm sucks or how much semver sucks
<alexgordon>
ec: semver is a good component, but there are complementary systems
<ec>
alexgordon: luckily, this is the *one* good PLT idea that I've managed to avoid involving in Paws :P
<alexgordon>
ec: like a type signature
<ec>
maybe I'll work with some people to implement it for JavaScript someday
<ec>
yeah.
<glowcoil>
ec: tbh languages are starting to have "async" keywords everywhere
<alexgordon>
the interface of a function is part of it
<alexgordon>
the unit tests are part of it
<ec>
I think A Version as a property of a *module* is a Huge Fucking Mistake
<glowcoil>
which is like actually fundamentally the same thing
<alexgordon>
sup micah
<ec>
alexgordon: yeah, exactly.
<ljharb>
ec: what would a version be a property of
<ec>
well. close, anyway.
<alexgordon>
brb scones
<ljharb>
if you mean the interface and observable semantics, sure, but most languages don't have that capability.
<ec>
ljharb: a single, atomic API endpoint. (function, or tuple of type-signature/return, or similar.)
<ec>
no, not the semantics; that's the part that's intentionally human-versioned.
<ec>
fun fact: having done a lot of thought on this, I've concluded that it's *impossible* to do this in a reliable, globally-strong way, without making it Actually Syntax.
<glowcoil>
hi alexgordon
<ec>
if I were to do a language focused on my versioning-related-thoughts, I think the *version* of an API you're calling would be a fundamental element of the *calling* syntax
<ec>
i.e. `foo(bar)` would be meaningless/impossible, you'd have to specify the equivalent of `foo@1(bar)`; so on and so forth
<glowcoil>
sounds awful
<glowcoil>
;-)
<ec>
obviously, with syntactic sugar and some ease-of-use approximations
<ec>
glowcoil: I don't disagree; I don't *remotely* know how to make this usable
* glowcoil
nodes
<ljharb>
ec: right ok so absent the possibility or capability of doing it - what's the next best option?
<ec>
but I just don't see a way that it will *ever* be less-than-janky-as-fuck to keep on decoupling `foo(bar)` and *what `foo` actually means* by putting the latter in a package.json or requirements.txt
<ec>
but yeah, the system that's taking form in my plans basically looks like this:
<ec>
the “version” of a package of code, is the tuple of the *actual* versions of every single API endpoint (let's say function, and pretend we're talking about future changes to JS, because everybody here knows JS well, and it's a nice lingua franca)
<alexgordon>
let's not even think about "packages", just functions
<ec>
nono this is important
<ec>
it's trivial at the fully-granular level; the only interesting problem in versioning is resolving dependencies between *mutually incompatible* sets of granules
<alexgordon>
if I use a package for function A, then function B has a breaking change but I never used function B, then there hasn't actually been a breaking change from my perspective
<ec>
the *required* “version” (as above defined) of a given package you use in *your* code, is a similar hash of each endpoint of that package that's *actually referenced* in your code
<ec>
yeah, precisely
<ec>
that's also why specifying which version you're calling *at the callsite* (or very nearby; yes, I think aliasing is okay, but no, I don't think aliasing it from *outside the file* or even *outside the whole damn language* is okay) is important:
<alexgordon>
and if you use structural typing, then you don't need to worry about versioning data structures either
<ec>
syntax wise, I've been idly considering using prime notation; that doesn't scale, but it works nicely for these discussions
<ec>
so if I'm `foo` and I call somebody else's `bar`, but then that somebody else publishes `bar'`,
<ec>
then `foo` needs to no longer *work* until the developer goes and manually verifies that either A) the breaking changes that caused bar's developer to increment the version definitely don't affect my foo's particular usage of bar,
<ec>
or B) they do, and I have now made the changes to foo that make it compatible with bar'
<alexgordon>
if you use static types there's a guarantee built in
<ec>
(thus obviously creating foo')
<ec>
so you *literally* have to open the code for foo, and change it one way or another
<ec>
either changing the callsite for bar to use the new signature, for example, maybe renaming an argument for a trivial example,
<ec>
or at least manually verifying that you know you don't need to, by exchanging bar' for bar
<alexgordon>
yes yes but half of the "breaking" changes are just changes in interface, which can be automatically verified
<alexgordon>
like when a function is removed and replaced with another function
<ec>
the only real *moving parts* in this system, is the machinery submitting ‘packages’ to a central namespace: a given package-name needs to be associated with a Comparable value of some sort
<ec>
a hash that can be compared very quickly against a consuming library's API-surface
<ec>
alexgordon: yeah, the combination of this sort of hashed-versioned-API with a strongly-typed language would *solve* an immense class of dependency problems
<alexgordon>
exactly
<alexgordon>
and throw in unit tests too
<ec>
well, here's how I see tests and code-changes working in:
<ec>
instead of human-elected ‘major’ and ‘minor’ and ‘patch’ and ‘generation’ and ‘guys this is getting ridiculous’ and ‘why does a *number*’ and ‘have multiple fucking components’ and ‘seriously why aren't they just comparable as floats’ and ‘geeze we're bad at computers, though, for real’
<ec>
the only *human* election in the system would be “is this commit breaking.”
<alexgordon>
say you have a function F1, which has tests T1. Then that function is modified to F2, and tests T2
<alexgordon>
T1 and T2 are predicates on the function
<alexgordon>
you can test F2 with tests T1
<ljharb>
ec: you can't do that unless you have a language where you can statically prove correctness
<ec>
the actual number would just be “<commits-marked-as-breaking>.<commits>”, where ‘commit’ is ‘any changeset touching *either* the body of this function, or referencing a new version of something this function invokes’
<alexgordon>
i.e. if the new function passes the old tests, it's probably? compatible. if it doesn't then it's definitely not!
<ec>
alexgordon: I'd really rather not have the system make any allusions on deciding ‘breaking’-ness
<ec>
not so much because it's not possible to make it do so mostly correctly,
<alexgordon>
ec: well I see it like this. you can never have an automated system say that a particular function is NOT breaking
<ec>
but because one of the major benefits of my design, as I see it, is the *strong requirement of responsibility* it places on the developers you rely on.
<alexgordon>
ec: but you can have one that tells you when it IS
<ec>
no longer is there any wishy-washy ‘well, I upgraded this’ or ‘you shouldn't have been using this in that way’ or ‘maybe that's a regression’ or,
<alexgordon>
as ljharb said, it's not possible for any automated system to decide "breakingness"
<ec>
it's a simple boolean “Did this change I just made, change the semantics of this particular API endpoint, at all?”
<ec>
if so, then boom, increment.
<alexgordon>
*or rather, not-breakingness
<ec>
alexgordon: yes, but again: I want the onus to be on the human for human reasons, not for any particular incapability of the computer
<ljharb>
ec: yes but "change" isn't what people care about
<ljharb>
"breaking" is
<ec>
I like to design software to influence people who design software
<ljharb>
if "change" is "add something new but all old stuff isn't broken" then that's not the same thing.
<ec>
ljharb: yes, pretty sure that's what I just said
<ljharb>
“Did this change I just made, change the semantics of this particular API endpoint, at all?”
<alexgordon>
ec: I think you'd be surprised how far a good static type system goes though
<ljharb>
that covers minor + patch
<ljharb>
sorry major + minor
<alexgordon>
e.g. I know that (a -> b) -> [a] -> [b] is map
<alexgordon>
real world apis tend to be some kind of structure of keyword arguments
<ec>
I have so much fucking trouble reading Haskell type signatures |=
<alexgordon>
maybe that is your first task :P
<ec>
dude, I've been trying since fucking 2010, when micah insisted on using them to discuss Paws concepts
<ec>
my brain literally cannot swallow them.
<alexgordon>
you know how to read it?
<ec>
it's the biggest barrier in learning Haskell. I've tried approximately once a year *since* then.
<alexgordon>
(a -> b) is a function from a to b
<alexgordon>
[a] is a list
<ec>
yes, I just have to stare at it for about ten minutes before I can figure out what it *means*.
<alexgordon>
and multiple -> means multiple arguments, except the last which is a return value
<alexgordon>
a -> b -> c means function(a, b) -> c
<alexgordon>
thereabouts
<ec>
I'd *love* to see a common, simple format for expressing type information that *didn't* depend on currying; I think that'd help a lot.
<ec>
yes, I know, alexgordon :P
<alexgordon>
ec: just use tuples
<ec>
I just have to do all of that translation, in my head, every single time.
<alexgordon>
(a, b) -> c
<ec>
*also* doesn't help that Haskell type-signatures special-case lists/arrays/whatever
<alexgordon>
I agree currying doesn't make sense outside the context of haskell
<ec>
why the fuck is [], a thing I think of as a *data* thing, not a *metadata* thing,
<ec>
in the *metadata* description format? ಠ_ಠ
<ec>
no, currying itself makes plenty of sense
<ec>
just stretching it to *describe* the format of a given task, does not.
<alexgordon>
it doesn't make sense to describe a language that doesn't use it
<ec>
anyway, still can't puzzle out (a -> b) -> [a] -> [b].
<alexgordon>
I just explained it -_-
<alexgordon>
you take a function, and a list
<alexgordon>
you return another list
<alexgordon>
the function maps from A to B
<alexgordon>
so the result is a list of B
<ec>
the argument I was *trying* to move towards making, but got sidetracked by how bitter that type-signature made me, :P
<ec>
was that yes, you know it's a map-*Y* function, but you don't know that it's map.
<ec>
semantics are more than signature.
<ec>
that was the big realization that destroyed my original plan, which was to build a hashed-versioning system by hashing all of the signatures together, and calling it breaking when the signature changes >,>
<ja>
fuck you and all your text biatches
<ja>
s/text/*text*
<alexgordon>
sup ja
<ja>
sorry hi
<ja>
just chillin
<alexgordon>
ec: if you knew haskell, you might start to doubt whether "semantics are more than a signature"
<ec>
sorry hej
<ja>
i should work on my game
<mkroman>
no.
<ja>
undskyld ec
<ja>
yes, mr. mr
<ja>
mk
<ja>
d
<ja>
hi
<purr>
ja: hi!
<ec>
mr mr mk d hi
* ja
might still be drunk from the day before yesterday
<ja>
yes, that's my pet name for mkroman
<mkroman>
ole wants you to start working on the new game so he has something to do, ja
<ja>
I don't give *a* *shit* about his fucking game right now, mkroman, but *don't* quote me on that
<alexgordon>
ec: so I was going to explain to you something
<ec>
alexgordon: basically, the point is,
* alexgordon
reads scrollback to try to remember what it ws
<alexgordon>
*was
<ec>
that when I type `foo@3`, I have a strong implicit guarantee *by a human* that typing that will do what I expect, *until I change it* to `foo@4`.
<ec>
(and, obviously, as we're on the same page about this part, that that guarantee be as granular as possible)
<alexgordon>
humans are overrated
<ec>
if `foo@3` does something different when I didn't change it, then that's an explicit bug, that is explicitly somebody else's fault; not the consumer's fault for not paying enough attention.
<alexgordon>
that is true
<ja>
ec: I think you should make it so typing `*something* *in* *asterisks*` in Paws does something
<ec>
i.e. `foo` is bugged, has introduced a regression, or a breaking change in an edge-case semantic
<ec>
ja you don't even know paws shush
<ec>
go write a paws and then tell me
<ja>
**double** asterisks *too*
<ja>
no, but I know about *you*, ec
* ec
gently shoves ja towards their keyboard
<alexgordon>
!what
<alexgordon>
-what
<purr>
<elliottcable> I'm racist as all fuck when it comes to sex
<alexgordon>
good to know
<alexgordon>
-what
<ec>
O_O
<purr>
<alexgordon> only elliottcable could unwittingly name something after bloody anuses
<ec>
old and uncomfortable-making
<alexgordon>
aha
<alexgordon>
god damn "piles"
<ec>
thank the lord the Internet is forgiving of one's past, and accepting of the fact that people can change
<ec>
right?
<ec>
… right?
<ec>
... guise, right?
<ec>
alexgordon: math piles!
<ec>
wheee
<ja>
no.
<alexgordon>
"Symptoms of math piles may include:
<alexgordon>
- bleeding after passing a stool (the blood will be bright red)
<ec>
why am I in IRC
<alexgordon>
- itchy bottom
<alexgordon>
- a lump hanging down outside of the anus, which may need to be pushed back in after passing a stool
<ec>
I have done nothing of value for hours
<alexgordon>
ec: this is value! :(
<ec>
meh, if I'd been able to clearly state my thoughts, perhaps
<ec>
or care more about the topic
<ec>
but I have too much A) Vagrant-tutorial-writing, and B) Paws. in my head to fit a third major Tech Train of Thought
<ec>
and I can't even focus on either of those active trains, because irl problems