ec changed the topic of #elliottcable to: a ~ℙ
<glowcoil> hi pikajude have i met you before ˇºˇ
Rurik has quit [Ping timeout: 244 seconds]
<pikajude> ya
<pikajude> its otters
<pikajude> /joelteon
<pikajude> or whatever else my username was
Rurik has joined #elliottcable
Rurik has joined #elliottcable
Hrorek has joined #elliottcable
Rurik has quit [Ping timeout: 264 seconds]
Hrorek has quit [Ping timeout: 250 seconds]
Rurik has joined #elliottcable
Rurik has quit [Ping timeout: 256 seconds]
Rurik has joined #elliottcable
<alexgordon> ec: around?
Rurik has quit [Ping timeout: 240 seconds]
Rurik has joined #elliottcable
Rurik has joined #elliottcable
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…]
eligrey has joined #elliottcable
alexgordon has joined #elliottcable
<ec> -ovoids
<ec> pikajude: wat.
<purr> beep.
<ec> alexgordon: what did you want?
<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
<alexgordon> ok looking
<alexgordon> it ends up on HN every six months
<ec> lol
<purr> lol
<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
<alexgordon> LOL
<purr> LOL
<ec> functionality not being allowed to compose
<ec> mmmm
<mkroman> any Rust programmers in the house?
<alexgordon> mkroman: no :P
<ec> mkroman: super-kinda-a-litte-bit-not-really. why?
<ec> half the people in this room have tinkered, though.
<mkroman> just curious :p
<ec> there's a terrible Rust Paws somewhere that only implements the datatypes, and none of the interesting shit.
<ec> :P
<ec> ugh leaving
<ec> bye
<alexgordon> rust is everything I ever wanted, until I tried it and realised I hate it
<ec> hate you all
<ec> hate hate hate you al all all
<ec> alexgordon: y
<ec> y u h8
<ec> y u no <3
<alexgordon> ec: later
<mkroman> y u h8 m8
<alexgordon> mkroman: I dunno, I got pissed off that you can't sort a list of floats in Rust. apparently it's "unsafe"
<ec> why are dogs better than Kate?
<ec> 'cuz k8 ≤ k9
<alexgordon> rust is so ivory tower
<mkroman> alexgordon: when was this?
<alexgordon> mkroman: last year
<mkroman> oh, much has happened since then
<alexgordon> I mean you _can_ but they made it difficult because "you shouldn't be doing that"
<mkroman> namely the stable release, and 4 minor versions since then
<alexgordon> it's more the attitude really
<alexgordon> I don't feel like they're interested in solving real problems, they just want to "make everything safe"
<alexgordon> well... the safest thing to do is not to write code in the first place
<alexgordon> then it can't be wrong
<alexgordon> I do like the language though, just not the management
<mkroman> fortunately I haven't had the need to sort any floats :p
<alexgordon> yeah I do a lot of numerical stuff
eligrey has quit [Ping timeout: 244 seconds]
<alexgordon> hmmmm
<alexgordon> how does one install codemirror?
<alexgordon> oh wait, found it
eligrey has joined #elliottcable
<alexgordon> wooot
<ec> alexgordon: confused about the sort-floats thing
<alexgordon> ec: eh it's not interesting
<alexgordon> you can't do say [ 1.1, 2.2, 3.3 ].sort() or whatever the rust equivalent is
<alexgordon> because the list might have a NaN
<alexgordon> never mind that it _doesn't_
<alexgordon> so you have to use this arcane ritual in order to sort an array of floats
<alexgordon> and for someone like me who does lots of numerical modelling, I cannot be arsed
<ec> so confused
<ec> what do you mean by arcane ritual?
<ec> basically, an Array<Float, Null> requires different efforts than Array<Float>, right? or something?
<ec> I barely understand type theory as it is :P
<alexgordon> ec xs.sort_by(|a, b| a.partial_cmp(b).unwrap_or(Less))
<alexgordon> it's even worse than C++ :O
<alexgordon> std::sort(xs.begin(), xs.end())
<ec> Ruby *just* had this discussion, interestingly enough
<ec> and arrived, ten years goddamn late, at the conclusion that yes, we need a *syntactic* un-nulling navigation operator
<ec> and hilariously enough after just two days' discussion on the mailing list, they committed it in a single patch
<alexgordon> it's not about null...
<alexgordon> it's about NaN
<ec> like, it was so anticlimactic, when everybody's been grumbling about not having it for years
<ec> Rust *has* NaNs?
<alexgordon> yes
<alexgordon> it's IEEE float
<alexgordon> they all have NaNs
<alexgordon> whenever you do 0.0/0.0 you get NaN, in any programming language that uses floats
<ec> hm
* ec backs up
<ec> so, how come Rust treats them specially?
<mkroman> is there any reason why IEEE would define it as NaN rather than just 0.0?
<alexgordon> ec: it doesn't, that's the thing
<alexgordon> ec: but what they say is, if you have a list of floats, some of them may be NaN
<alexgordon> and there's no defined order for that, so you're not allowed to sort it
<ec> ohhhhhhhhhh
<alexgordon> which is OAIWJDOIAWJDOIAWJD because if you're say randomly sampling floats from a distribution, there's not going to be any NaNs in there
<alexgordon> anyway I got pissed off trying to argue this with them because it's like ivory tower language design. not enough focus on practicality
<ec> -learn OAIWJDOIAWJDOIAWJD=which is Rust
<purr> ec: Learned `OAIWJDOIAWJDOIAWJD`.
<alexgordon> ec: so, prototype is almost done
<alexgordon> made a little wiki
<ec> this reply to that thing:
<ec> nailed a *huge* thing that's been on my mind
<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
<alexgordon> requests.get is { url: String, headers: Dict, ... etc }
<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
<alexgordon> vagrant tutorial writing?
<mkroman> ja: Santorum.
<ja> mkroman: u wot m8
<alexgordon> ec: are they paying you?
<ec> basically, the entire Internet has failed to explain containers to me, and in the Burritutorial Spirit, I'm going to write my own
<ec> alexgordon: when was the last time anybody paid me to do anything
<alexgordon> good point
<ec> except eligrey, apparently, offering every two minutes
<alexgordon> eligrey: you can't afford him
<eligrey> i don't plan on paying him as much as you think i would
<eligrey> and it's not like he'd work for the money, he'd only work for the sake of making something cool