<alexgordon>
which is pretty cool, if possibly useless
<glowcoil>
oooooh
<alexgordon>
but it's a kind of directed graph, you can start at one end (e.g. group) and then find all the concepts you need to know to learn what a group is
<alexgordon>
I was trying to put mathematics in order. perhaps the most autistic thing ever imagined
<glowcoil>
ec: ok what *are* containers
<glowcoil>
alexgordon: no i like it
<glowcoil>
actually a rly great idea
<alexgordon>
some day I'm going to make a website where you can just go back and forwards in the dependency graph
<alexgordon>
or like "I want to learn what a Homotopy Group is, show me the minimal sequence of concepts I need to learn that"
* glowcoil
nods
<alexgordon>
glowcoil: so I'm trying to make wiki for programming...
<alexgordon>
a programming language as a wiki
<alexgordon>
basically the core problem is, how do you manage something that changes really fast like a wiki?
<alexgordon>
if every page of the wiki represents a function, or a section of the whole program/library, then how do you manage breakage when everybody can edit any article at any time
<alexgordon>
obviously there's the history, so it's not totally impossible
<alexgordon>
hmmmmmmmmmmmm integration tests
<alexgordon>
so imagine our wiki is a collection of functions, and each function has a stack of versions, then what you want is the collection of versions of functions that pass the integration tests
* alexgordon
channels ec's craziness
<alexgordon>
ok so that's one part of it. then there's the naming. each function should have a uuid, so that the name can change without it breaking other code
<alexgordon>
yay figured it all out
<alexgordon>
ec: wake up! :P
alexgordon has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
alexgordon has joined #elliottcable
Hrorek has quit [Ping timeout: 240 seconds]
Hrorek has joined #elliottcable
eligrey_ has joined #elliottcable
eligrey has quit [Ping timeout: 244 seconds]
Rurik has joined #elliottcable
Hrorek has quit [Ping timeout: 244 seconds]
yrashk has quit [Quit: Connection closed for inactivity]
alexgordon has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
bluebie has quit [Quit: Connection closed for inactivity]
eligrey_ has quit [Quit: Leaving]
Rurik has quit [Ping timeout: 240 seconds]
Rurik has joined #elliottcable
Rurik has quit [Remote host closed the connection]
Guest12108 has joined #elliottcable
Guest12108 has quit [Quit: Leaving]
Hrorek has joined #elliottcable
amatecha has joined #elliottcable
alexgordon has joined #elliottcable
alexgordon has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
alexgordon has joined #elliottcable
alexgordon has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
alexgordon has joined #elliottcable
Hrorekr has joined #elliottcable
Hrorek has quit [Ping timeout: 265 seconds]
alexgordon has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<pikajude>
i'm about to fly to germany
<ja>
cool
<ja>
wherefrom?
* ja
is surprised “wherefrom” is a word, albeit archaic
<ja>
pikajude: what sounds better? “span” or “period”, when talking about time?
<pikajude>
ja: san francisco
<pikajude>
ja: context
<ja>
writing “period” every where in my code almost makes me menstruate :c
<ja>
pikajude: ah. what's happening in Germany?
<ja>
context sounds too general to me. I've never heard anyone say “time context” before.
<pikajude>
ja: nixcon
<pikajude>
ja: span then
<Hrorekr>
anyone here knows about compilers
<pikajude>
i use them occasionally
<mkroman>
ja: speaking of Germany, are we going to CCC?
<pikajude>
AMA
<ja>
pikajude: the men's watches company?
<ja>
or a unix conference?
<ja>
pikajude: so you agree that “period” sounds rather menstruative?
<alexgordon>
yeah although if you target llvm there's not much of that to do
<Hrorekr>
I have a very vague idea of these terms
<Hrorekr>
I'd like to hack on Google's V8 after I am done learning
<alexgordon>
Hrorekr: lexing = split into a stream of tokens. parsing -> make a parse tree, semantic analysis -> make an abstract syntax tree, code generation -> produce the target output
<alexgordon>
there's no rules other than that. ghc is built _very_ differently to clang, they are both good compilers.
<alexgordon>
^ that is a good practical guide to the innards of ghc
<alexgordon>
Hrorekr: yeah. in my experience it's always best to use a lexer generator, rather than to make one yourself
eligrey has joined #elliottcable
<alexgordon>
like if you're writing a compiler in c/c++, you use Ragel for the lexer
<Hrorekr>
except I don't know C
<Hrorekr>
I always abandon it when it comes to pointers
<Hrorekr>
I just don't get them
<alexgordon>
well then don't write a compiler in c!
<alexgordon>
I'm making one in JS
eligrey has quit [Quit: Leaving]
eligrey has joined #elliottcable
<ec>
my cape has a Mojang logo
<ec>
alexgordon: I have Opinions on your idea
<alexgordon>
ec: I haven't told you it yet
<ec>
mostly because another community I'm in has *already been discussing this precise thing*
<alexgordon>
I had a big think
<alexgordon>
and I worked it out
<ec>
as *well* as talking about it in here with ljharb a lot a couple days ago
<ec>
alexgordon:
<ec>
lol.
<purr>
lol
<alexgordon>
ec: well explain to me your opinions
<ec>
anyway, I'mma be showering and packing and driving for the next ~4 hours, and then playing
<alexgordon>
and what you were talking about in the other place
<alexgordon>
lol or not
<ec>
but I can talk cool plt stuff a bit late
<ec>
alexgordon: did you read the linked ancient erlang thing about giant-bag-of-implementation?
<alexgordon>
k just ping me when you're around
<ec>
that's kind of wiki-ish
<alexgordon>
ec: yeah I linked it to _you_
<ec>
and then I *really* think you should steal my idea of making ‘version’ first-class
<alexgordon>
lol
<ec>
i.e. required / obvious / encoded
<ec>
as opposed to optional / obtuse / out-of-band
<ja>
I need to get my irssi to support emojis
<alexgordon>
what do you mean first-class?
<ec>
take those two, and then replace his ‘database’ idea (API) with an editor / website (UI),
<ec>
and I think you have a neat idea.
<alexgordon>
yeah
<alexgordon>
well what I've solved is the resilience problem
<ec>
first-class as in, make ‘a version of a thing’ the ‘object’ in ‘object-oriented’
<alexgordon>
oh I see
<ec>
as in, *everything* has a version, and the *version* of something is its' most essential property
<alexgordon>
yes I have already
<ec>
version comes first, everything else comes second
<alexgordon>
it's simpler than that
<ec>
brb shower and schtuff
<ec>
(if you're going with that, here was my thoughts:
<ec>
make it impossible to reference something unversioned *in general*, but allow the aliasing of versions
<ec>
i.e. `foo = foo@3`
<ec>
then also provide a nice short-hand for small version numbers; because a lot of time, small/simple/edge APIs will have very small version numbers; 'cuz they don't often change as much after creation
<ec>
foo@3 == foo''', or something
<ec>
so, for Big APIs, you basically do the equivalent of `foo = require('foo')@3`, if this were javascript or whatever, at the start of a given scope;
<alexgordon>
ec yes yes I have worked it out :P
<ec>
and for small APIs you just assign the version at the callsite, `foo.bar''`
* ec
shrugs
<purr>
¯\(º_o)/¯
<ec>
just sharing my thoughts!
<alexgordon>
ec: it's good, we have the same ideas
<ec>
tell me more about what you came up with, will read while driving
<ec>
happy to help with impl at some point too, if you're serious about this
<alexgordon>
sure, let's do it
<ec>
i.e. more-serious than “I'm going to forget before the week's out” :P
<alexgordon>
I already made the wiki
<ec>
lol.
<purr>
lol
<ec>
what are your *langauge semantics*
<ec>
this is all one aspect of a language
<ec>
I could tack this pretty easily onto JavaScript, for instance
<ec>
or Paws
<ec>
actually
<ec>
hm
<ec>
doing this as a JavaScript pre-compiler could be a Really Good Idea.
<ec>
but you hate JS. >,>
<alexgordon>
no no I am writing it in js
<ec>
but a giant wiki of Implementation Of Things, directly in competition with npm …
<ec>
or, perhaps, make it backwards compatible
<alexgordon>
not in competition
<alexgordon>
the opposite
<alexgordon>
I want to make it work with npm
<ec>
“embrace and extend”
<alexgordon>
more inclusivity, not isolation]
<ec>
personally: nah. I'm convinced this has to be holistic.
<alexgordon>
I want to make it work with rubygems too
<ec>
have to encode *all* versioning.
<ec>
no getting away with “just put it in the package.json, I don't want to deal with it.”
<alexgordon>
yes, in its special area
<alexgordon>
but the outside world _exists_
<alexgordon>
at least at first
<ec>
wait how the crap does it work with gems *and* javascript
<alexgordon>
:D
<ec>
two languages? wat
<alexgordon>
stretch goal :P
<alexgordon>
anyway the main thing is to get the wiki working
<alexgordon>
everything else will come with time
<ec>
not sure I see how
<alexgordon>
ec: the ruby thing? it's quite easy to bridge into ruby, there is an api
<ec>
I dreamed somebody told me my old C-unit-testing-tool was a Good Idea
<alexgordon>
it's a wiki, but for axiomising mathematics
<mkroman>
ec: X_x
<alexgordon>
ugh deploying django sucks
<alexgordon>
I should have used express
<ec>
alexgordon: I followed the links yes
<ec>
or rather, opened them in tabs to look at later
<ec>
okay, you literally mean, a website wiki
<ec>
with … pages
<ec>
yeah, not nearly as sold
<ec>
nobody, anywhere, ever, wants to write code in a webpage
<ec>
(slight exaggeration; but I feel justified in ignoring <the entire set of people who do>, because they're all idiots)
<ec>
</opinion>
<ec>
but nonetheless: even if you *want* a website for it, I'd say First Goal should definitely be the backend/api, and a terminal client that … idk, grabs code from, or extracts, or breaks-apart, Or Whatever, *files*, on your filesystem
<ec>
and retrieves them from the server and turns it into files, I guess? or something?
<ec>
idk any of that happy to discuss specifics later, I feel like your ideas on that and mine are going to Differ Strongly, But That Is Okay,
<alexgordon>
ec: nothing has to be set in stone
<alexgordon>
a website would work well as a prototype
<ec>
but point is: filesystem/files/`node`-at-a-bash-terminal is *way* more current-real-world relevant than … a webpage to copy/paste code into/out-of
<alexgordon>
if someone wants to make a terminal client too, that's fine
<alexgordon>
the main thing is to have a _backend_
<ec>
if you *really* want to go hard on a UI, then … at least make it an editor plugin, vim or emacs or atom or sublime,
<ec>
not a webpage ;_;
<ec>
no that's my point
<ec>
the experimental UI *very* much shapes the core ideas, protocol, usage pattern, whatever
<alexgordon>
ec: actually I found that the code units are so small (maybe 20 lines per page tops) that you don't need a full text editor
<ec>
and starting out with a webpage feels like a huge mistake
<ec>
yah that's my point
<ec>
it's less about the pages and the editing-in-a-text-area,
<ec>
and more about them being *seperate*
<ec>
the desperately important thing to me, here, is that all of the functions or modules or whatever I'm currently working on contributing *stay in my editor window*, in a single file, because that's how I'm going to run them
<alexgordon>
mmmm
<ec>
if I have to constantly copy-paste small sections of code back and forth from the Actually Runnable format (a file full of many of them) into the Interface Format (individual pages in a browser), … eek.
<ec>
so like, the, … mapping-of-formats feels like it's almost certain the Most Important Aspect of this entire thing.
<ec>
does that make sense?
<alexgordon>
what this is telling me, is that there needs to be a clear separation between server and UI
<ec>
100% agreed
<alexgordon>
i.e. you have a server that speaks HTTP and JSON
<ec>
I think this concept inherently needs to be a (Design and an API),
<alexgordon>
then the website is _one_ client
<ec>
.ahhhhh 100% agreed
<alexgordon>
and vim could be another client
<ec>
all the UIs should be irrelevant at this point as much as possible
<ec>
obviously we need something to test with
<alexgordon>
ya
<ec>
but we should be suuuuuuuuper-skeptical of any decisions our testing-UI makes us make.
<ec>
either tat
<alexgordon>
then also people can write their own federated servers
<alexgordon>
* run
<ec>
or try and take the desperate failed Paws approach
<alexgordon>
lol we are building google wave for code
<purr>
lol
<ec>
of having like six implementations / APIs in parallel, competing with eachother for opinions
<alexgordon>
---_---
<ec>
ew no
<ec>
1. fuck federation, false flag and waste of design time, my 2¢,
<ec>
2. fuck real-time co-editing, that's not our problem or domain
<alexgordon>
well people will want to run private servers for their own private code
<ec>
(a revision is a revision, if it comes in later or earlier doesn't matter to us, because we're going to be *content-addressing* anyway)
<ec>
(… please tell me we're going to be content-addressing?)
<alexgordon>
yes
<alexgordon>
sort of
<ec>
sure, it can be open source
<ec>
but I'm all for authoritative root service. ¯\_(ツ)_/¯
<alexgordon>
yeah
<ec>
here's how I see the core concept:
<alexgordon>
well you can merge stuff in
<alexgordon>
man this is the most agreement we've had in the last 6 years
<ec>
“A *mapping* of <naming/identifier/namespace-member> to <content-hash of canonical serialization of AST>.”
<ec>
changing the AST (that is, the code), changes the hash, which when mapped to the same ‘identifier/name’, means a new “version” exists.
<ec>
that is … all there needs to be, IMHO, at the start.
<alexgordon>
yeah
<alexgordon>
I am calling that a "package"
<ec>
all sorts of things like branching, interfaces, comes later on, right?
<ec>
the identifier-name-bit?
<alexgordon>
package = map from qualified names to hashes PLUS any integration tests
<alexgordon>
the integration tests are the important bit
<ec>
do you have a *required* scope? i.e. are you hard-coding ‘every package is a single function’ or ‘every package is a single module’ or,
<ec>
or is it just … any “chunk of code” you want to?
<ec>
waaaaait
<ec>
1. tell me more, huh? tests?
<ec>
2. *integration* tests? y not unit?
<alexgordon>
unit tests go with each function
<ec>
and I have to leave again I shouldn't have been here talking
<alexgordon>
integration tests go with each package
<alexgordon>
makes sense, no?
Hrorekr has quit [Ping timeout: 255 seconds]
<ja>
google wave for code sounds great
<ec>
but glad we agree that “UI is least-important right now” and “this is basically, when it all come down to it, a data-mapping of <name> to <code> through <version>”
<ec>
hrm
<ec>
personally, I would make this simpler, and call every single function a package
<ec>
or rather, just say it's a wiki of functions
<ec>
but that's because I come from node/npm right now
<ec>
and we're all suuuuuuuper-into Micro Packages
<alexgordon>
I dunno, the name doesn't matter
<ec>
oh hey I need to go but I *really* want to talk about my “function, and composition-of-functions, being *exclusive* concepts” idea that I talked about a few days ago
<alexgordon>
point is, you have a map from qualified names to hashes
<ec>
I just want to hear your thoughts on it, not necessarily selling it as an element of this wiki-project
<ec>
now bbl shower
<alexgordon>
k
<alexgordon>
ja: join us! lolol
<purr>
lolol
<alexgordon>
90% chance of failure
<alexgordon>
10% chance of wild success
<ja>
alexgordon: sure!
<alexgordon>
ja: are you on github?
<ja>
yes
<ja>
/alminde
<ja>
I really need ja on GitHub :<
<ja>
anyone got GitHub staff connections? >:D
<alexgordon>
you can email them
<alexgordon>
if it's unused
<alexgordon>
I want atg
<ja>
well, he has a picture and all
<ja>
and some repos
<ja>
so it's not really that used compared to other profiles i've come across
<ja>
which were completely blank
<ja>
like atg, that looks very unused
<ja>
most of ja's stuff is from 2008 or 2009, hmm… I wonder if that's unused enough
<alexgordon>
I am taking the initiative and calling it bhasa which is sanskrit for language
<ja>
“Bhāsa is one of the earliest and most celebrated Indian playwrights in Sanskrit. However, very little is known about him.” — hah
<alexgordon>
yeah fuck that guy
<ja>
yeah, fuck 'im
<ja>
Phasa reads cooler and less African-sounding than Bhasa, imho
<ja>
that is a cool name though
<ja>
due to its meaning
<alexgordon>
phasa sounds phallic :P
<ja>
yeah
<alexgordon>
tbh I just wanted something with a cool file extension. ".bh" is great
<ja>
mmmh cocks
<ja>
nice
<ja>
sounds very untaken
<ja>
“bh” is what we call bras in Danish
<alexgordon>
really?
<alexgordon>
excellent
<ec>
I like African-sounding
<ec>
leave it bhasa, my vote
<ja>
yeah, really
<ja>
BREAST HOLDER
<alexgordon>
LOL
<purr>
LOL
<ec>
now stop bikeshedding and talk to me about versioning, ja
<ec>
so, I take it that writing the client-side that chunks code and standardizes/hashes the AST is falling on me, since alexgordon has already dived in on the server?
<ec>
talk to me about content-addressing / naming / how you want to do that, go!
<alexgordon>
it's simple
<alexgordon>
you need two components: 1) a UUID (not a hash) to refer to the function itself
<alexgordon>
there is nothing to hash, see
<ja>
yeah, sorry about the bikeshedding
<alexgordon>
THEN
<alexgordon>
a hash for each version of the function
<ja>
I gotta work though; brb
<ec>
uuid is a mapping for a name, then
<ec>
so that the name can change
<ec>
right?
<alexgordon>
exactly
<ec>
uuid == purpose
<alexgordon>
the name is part of the version
<ec>
hash == implementation
<alexgordon>
if you change the name, you make a new version
<ec>
no wait
<ec>
IDEA
<ec>
ALEX, IDEA OMG
<alexgordon>
lol go
<ec>
you're going to love me.
<alexgordon>
uh oh
<ec>
let's NOT conflate (tests^code); let's intentionally break them apart, conceptually
<ec>
hear me out
<ec>
idk specifics but, like, as an example,
<ec>
instead of UUID == intent and hash-of-code == implementation,
<ec>
*hash-of-tests == intent*, and hash-of-code == implementation
<ec>
wait, now,
<ec>
this way, the name is a changeable property, but the *intent*, is not
<ec>
if you add new tests, in this system, you've *inherently* created a new *thing*.
<alexgordon>
wellllll
<ec>
like, a new, actual, thing.
<alexgordon>
I know this is like your first idea
<alexgordon>
but
<alexgordon>
ec: when you start, you have no tests!
<ec>
the Thingness of something is dependant on the specific tests.
<alexgordon>
so all functions would have the same id
<ec>
no, this forces TDD
<ec>
you *must* write tests, to create a new thingness, a new ‘intent,’
<ec>
then you can write the first implementation of that test.
<alexgordon>
yeah but, what if you want to add new tests
<ec>
this, like, maps perfectly to the ideal-idea behind testing
<ec>
yes yes yes
<alexgordon>
then everybody has to go and change the hash
<ec>
that's the next iteration
<ec>
no hold on
<ec>
that's where naming comes in: name maps to intent, maps to implementation
<alexgordon>
please can we do a uuid lol, I got this all worked out
<purr>
lol
<ec>
not saying we can't, I'm flexible; but just hear me out for a second
<ec>
also omg glowcoil get your butt in on this
<alexgordon>
ec: there is space for that, but not as part of the function
<ec>
happy to go back to uuid == intent if this makes no sense ¯\_(ツ)_/¯
<ec>
but,
<ec>
basically: development comes down to two iterations, as one big process
<ec>
or rather development-if-you're-following-tdd
<ec>
you *start* with an intent in your head: you try to serialize this intention as a small set of a couple tests
<ec>
then you try to implement those tests with a tiny bit of code.
<ec>
you then realize the code doesn't work, because your tests *didn't* match your intention, and your intentions were actually slightly different; so you add new tests / create a new intention, that more closely matches your actual goal.
<ec>
… then implement that.
<alexgordon>
ec: we can do "hash of tests"
<alexgordon>
but you still need a uuid
<alexgordon>
so I guess... both
<alexgordon>
you need something that does NOT change
<ec>
meh ignore implementation of the server for a second
<ec>
I know you hate white-tower ;_;
<ec>
will try to concrete-ify asap
<ec>
but try and tell me what you think of the overall idea of *mapping* our giant-bag-of-implementation, to TDD as a process
<ec>
does that seem like a good idea?
<alexgordon>
hm I wish you knew more category theory :P
<ec>
in my mental model, here, we build on that TDD crap: creating a new ‘intention’ *is* creating a new package, basically
<alexgordon>
ec: let me explain mine and then you'll see there is no disagreement
<ec>
you can re-map the old name (old UUID, if you want to maintain that mediator between the linkage) to the new package, if the new package (the new intention) more clearly means what you mean
<ec>
yah go
<alexgordon>
ec: each "version" is a record. it's just data. THEN you have different pointers into that record
<alexgordon>
you can hash different parts of the data, to get different kinds of pointers
<alexgordon>
so like hashing the tests, gives you something that changes when the tests change
<ec>
mmhmm, yes, I realize that
<ec>
yes, but that's not what I'm talking about
<alexgordon>
or hashing the interface gives you something that changes when the interface changes
<ec>
sorry, focusing too much on the word ‘hash’ and missing actually expressing my point
<alexgordon>
the UUID is another kind of pointer, that basically _never_ changes
<ec>
my point, put in terms of the data-model instead of ivory-tower:
<ec>
I'm saying decouple the <name> from the <implementation> *entirely*,
<ec>
so that the only place they intersect is the <intent>.
<ec>
(slash the tests)
<ec>
<name> → <intent> → <implementation>
<alexgordon>
you have the right idea
<ec>
so in this model, I don't think we need a UUID, because we're using the hash-of-the-intent *as* the model.
<ec>
<intent> replaces ‘version.’
<ec>
or, to look at it another way,
<alexgordon>
ec: no you definitely do need a UUID politically
<ec>
1.2.3 => <intent>.<name>.<implementation>
<alexgordon>
if you don't use the uuid, people will start using the _name_ instead, and then that will create breakage
<ec>
refactoring or non-AST-changing-stuff can change the patch level, but is not allowed to be breaking
<ec>
the only *breaking* changes allowed, are *if the tests are changed*
<alexgordon>
you need to provide something that never changes
<ec>
and inherently, if the tests are changed, it's also a breaking change
<alexgordon>
lol we are bikeshedding over this
<purr>
lol
<ec>
hold on that's intentional though
<alexgordon>
yeah but human nature, ec. people are lazy
<ec>
how is bike shedding, seems pretty fundamental to the idea
<ec>
yes!
<alexgordon>
fundamentally, you can't enforce a particular way of using it
<alexgordon>
you can only nudge people into one way or the other
<ec>
sorry we're focused on different things; I'm still big on this being an implementation of my Make People Go Change Versions In Their Code All The Time grand-plan,
<ec>
you're still big on it being a Store All The Code In One Central Place grand-plan
<ec>
:x
<alexgordon>
no no
<ec>
have to compromise, I think? one way or the other? no?
<alexgordon>
I don't think we can tell people how to use it. we can suggest, but...
<ec>
sorry multitasking, my typing is suffering
<ec>
programming languages are *all about* enforcing/encouraging particular patterns of use through their fundamental design
<alexgordon>
yes but if you make it too onerous, people will work around the restrictions
<ec>
Haskell is All About discouraging global state, Paws was All About forming communities-of-practice/form,
* ec
nods
<alexgordon>
anyway I don't think there is a disagreement here
<ec>
let me say … a thing
<alexgordon>
you can absolutely do what you want to do
<ec>
that I'm worried you didn't get from the above
<alexgordon>
with the test hashes
<ec>
that being:
<ec>
basically, people typing `foo@3`
<ec>
if you change the name … they *have* to go change it to `newFoo@3`.
<ec>
and part of what you're saying, and what I agree with, is that that's inherently a versioned-change *anwyay*
Hrorekr has quit [Ping timeout: 240 seconds]
<alexgordon>
actually, no
<ec>
so that's `newFoo@4`, or possibly `newFoo@1`
<alexgordon>
there is another layer of indirection
<alexgordon>
let me explain
<ec>
mmhmm
<ec>
listening while I dress
<alexgordon>
a "package/module/whatever" is a mapping from NAMES to HASHES
<alexgordon>
ec: so people use "foo()" in their code, then they also define that "`foo` maps to <somehash>"
<alexgordon>
like an import declaration
<ec>
are you expecting them to type the hash into their code? Because I'm not down with that, I don't think
<ec>
I am also now I are seeing with voice to text, so this might get weird
<ec>
… especially el oh el
<alexgordon>
well I dunno
<alexgordon>
you would probably use a command line tool
<alexgordon>
like npm install --save
<alexgordon>
or an editor command
<alexgordon>
*shrug*
<purr>
¯\(º_o)/¯
<ec>
wish we could umbm
<ec>
Some Bluetooth accessories aren't supported on Apple TV (4th generation), including Bluetooth keyboards.
<alexgordon>
UI not important!
<ec>
ffffff wtf
<ec>
wish we could mumble
<ec>
or audio
<alexgordon>
the important thing is that there is data somewhere that maps the name, to the hash
<ec>
here was my thought:
<ec>
yahyahyah
<ec>
I agree,
<ec>
but that was, to me, the purpose of the version, right? because version changes with name-change, foo@3 is a forever-unique description of a particular hash
<alexgordon>
uh, I think we should just build this. lol
<purr>
lol
<ec>
don't need a uuid, necause although name can be remapped, name@version *cannot*. basically, version is an always-incrementing counter of changes to that name-hash mapping.
<alexgordon>
ec: yeah you don't need a uuid for that bit
<alexgordon>
but it helps for documentation purposes
<ec>
so what's the uuid for? I suspect I've just lost you, we might agree
<alexgordon>
the uuid is how you collect the different versions of the SAME function together
<alexgordon>
say you start with "fold() with a given implementation", then you change it to "reduce() with another implementation", you need something to tie those two together
<alexgordon>
that is the uuid
<alexgordon>
they will have totally different hashes
<alexgordon>
but they are the same function
Hrorekr has joined #elliottcable
alexgordon has quit [Read error: Connection reset by peer]
alexgordon has joined #elliottcable
<alexgordon>
ec: I get what the miscommunication is. you are thinking of a name at USE, whereas I am thinking of a name at DEFINITION
<alexgordon>
to me, the name at USE is irrelevant, because users are free to choose any name to use, as long as they specify the correct hash
<alexgordon>
so essentially I think we agree
alexgordon has quit [Read error: Connection reset by peer]
alexgordon has joined #elliottcable
<ec>
alexgordon: explain moar
<alexgordon>
ec: of what?
<pikajude>
im panicking
<alexgordon>
from what I can tell we agree
<pikajude>
im about to be in an airplane for 10 hours
<pikajude>
help me
<alexgordon>
pikajude; DON'T PANIC
* alexgordon
gives pikajude a towel
<ec>
sorry am afk-ish
<ec>
pikajude: can we help?
<ec>
alexgordon: I'm going to be working on my résumé some more; I *really* need to complete this application today and tomorrow,
<pikajude>
i don't know
<ec>
so I can't talk about cool new ideas too much right this mo'
<pikajude>
can i be tranquilized for the entire journey
* ec
re-reads your response, though
<alexgordon>
ec: it's fine, I'm on fire here *making the api*
* ec
laughs
<alexgordon>
ec: from what I can tell, it will work pretty much as you describe it
<alexgordon>
but I'm not exactly sure what you want
<alexgordon>
so
<ec>
throw up a fugly design-graph so I can comment?
<ec>
:D
<alexgordon>
I will just code
<alexgordon>
and then see what you say
<ec>
so basically if we're going to work together on this, it sounds like you're going to be writing a server and I'm going to be writing a client
<alexgordon>
not at all
<ec>
division wise: are you expecting to receive *code*, or *AST*, or *hash*?
<alexgordon>
I added you as a collaborator to the bhasa/server
<ec>
actually, both client and server should probably hash and confirm.
<ec>
durrr.
<ec>
sorry, I've never really worked on anything w/ hashes before. new to me. :D
<alexgordon>
I'm still working it out
<ec>
what are you coding in, JavaScript?
<alexgordon>
right now? markdown and json :P
<alexgordon>
it's a rest api
<ec>
slash CoffeeScript?
<ec>
ahhhhh k
<alexgordon>
_everything_ is json. that is the only rule :P even the AST is json
<ec>
for impl: if you want to collaborate on codebase, you down to just do ES6 and transpile? alternatively, I'm down to do this in Haskell, if you can try to keep your code super idiot-proof and beginner-level
<ec>
yeah I can do JSON AST, good by me
<ec>
ship in msgpack?
<alexgordon>
yeah maybe
<alexgordon>
es6 is fine, maybe
<ec>
impl bike shedding ignore me
<ec>
I just like playing with new toys ;P
<alexgordon>
I am just writing bog standard js ATM
<alexgordon>
ec: what kind of data store should the server use?
<ec>
hm
<alexgordon>
could do flat files (it is code after all)
<ec>
sequel ¯\_(ツ)_/¯
<ec>
just use Postgres or something
<ec>
simple af
<ec>
redis for caching and task-queue
<ec>
bog-standard
<ec>
I like bog-standard
<ec>
bog-standard is productive and relatively near-future-proof
<alexgordon>
yeah ok
<ec>
bog-standard is good for collaboration :P
<ec>
will say this tho:
<ec>
*if* this is at all a success even a little,
<ec>
database-format and transport-format will matter A Lot.
<ec>
I was seeing numbers for npm earlier today thanks to wasshisname, the cute one
<ec>
@seldo
<ec>
and it's terrifying.
<ec>
things serving code to other things get heavy traffic early on, because they're easily automated and beg for automation.)
<ec>
anyway. just a note. moving on.
<alexgordon>
yeah
<alexgordon>
ok
<alexgordon>
so
<ec>
alexgordon: can you give me a 10,000-foot over view of how you're imagining / modeling this?
<ec>
i.e. datamodel, client-server interaction, general patterns no specifics etc
<ec>
I need to get back to work here real soon, but I want to let my mind stew
<alexgordon>
you should maybe just read the protocol document after I've written it *shrug*
<purr>
¯\(º_o)/¯
<ec>
I know I sound super hurried and difficult today. I'm sorry. >:
<ec>
k lol okay
<purr>
lol
<alexgordon>
ec: the server stores "json stuff". when clients ask for "json stuff" it sends it
<alexgordon>
ec: clients can submit new "json stuff" to the server, which creates a new version
<alexgordon>
different clients do different things with the JSON stuff. e.g. a web client might present it prettily
<alexgordon>
whereas a package manager only cares about the code
<alexgordon>
but the server doesn't know anything about this. to the server, it's just kinda-opaque json
<alexgordon>
the server _is_ in charge of validating the json to make sure it matches the spec though
<pikajude>
are you talking about mongodb
<alexgordon>
pikajude: hehe that thought crossed my mind too
<pikajude>
it's crossing my mind right now
<alexgordon>
pikajude: well mongo db could be a backend to it... the server still has to validate the json though
<alexgordon>
I prefer postgres tbh
<alexgordon>
pikajude: also this is _append only_
<alexgordon>
"The only way to modify a function is to publish a new version to the server."
<pikajude>
what the fuck
<alexgordon>
pikajude: think wikipedia. when you edit an article, it just adds a new version
<pikajude>
WOM?
<alexgordon>
WOM?
<alexgordon>
Worldwide Oilfield Machine
<pikajude>
write-only memory
<alexgordon>
pikajude: I expect if this ever got big, the server would have to delta-encode each version as a patch
<alexgordon>
but for now I'm happy to store in full
<pikajude>
i just found out about the term "read-only language"
<pikajude>
and apparently the ROL of choice is applescript
<pikajude>
i 100% agree
<alexgordon>
haha that's excellent
<ec>
lmao
<ec>
ROL is fav
<ec>
alexgordon: yeah, patch will have to be a thing
<ec>
if this Works at all,
<ec>
we're going to have to start from scratch later and give this a real protocol, imho
<ec>
basically repurpose git and bitcoin ;)
<alexgordon>
:)
<ec>
but that's … irrelevant now. store in full in sequel, I'm all in for that.
<alexgordon>
open source baby, let other people do the hard work
<glowcoil>
hi
<purr>
glowcoil: hi!
<ec>
alexgordon: ProofWiki is SO GREAT
<alexgordon>
ikr
<ec>
like, this is So Fucking Much more understandable than the wikipedia article on the same topic, omfg.
<ec>
glowcoil: I don't know if I think this is GREAT, but it sounds genuinely-do-able in a relatively simple amount of time; is sufficiently PLT-y that it scratches my itch, and *could* be really useful
<ec>
I also actually am coming to like that it's not necessarily designed to be holistic:
<ec>
I like it as an idea that doesn't necessarily need to be the most popular thing ever to be useful; could be as simple as “put our transpolar in your build-pipeline, and you get access to a bunch of arbitrarily useful code, with the guarantee that it won't break due to versioning/upstream issues”
<ec>
transpiler*
<ec>
or “visit our website and copy-paste the community's implementation of this common JavaScript function into your utilities.js file; don't even bother with our transpiler, and know that it's seen a lot of revision by other programmers”
<ec>
(alexgordon: we should talk about discovery at some point.)
<alexgordon>
I think it will only work for stuff which is sufficiently broadly useful
<ec>
alexgordon: can't read that now, *really* need to stop being silly / thinking about this. have important things to do. )'=
<ec>
is this how you feel all the time? I hate it. don't ever let me get a job. ಠ_ಠ
<alexgordon>
lolol
<purr>
lolol
<ec>
oh that was short
<ec>
alexgordon: wat is this XOARED hash for?
<alexgordon>
ec: to hash multiple keys in an object
<alexgordon>
often you want to hash multiple things like "I want something that changes when either the parameters OR the type signature changes"
* ec
nods
<ec>
why XOR? idk much about crypto shit.
<alexgordon>
but you don't want the server to have to store a hash for every possible combination
<ec>
ahhhh because XOR doesn't care about order? what about three things?
<alexgordon>
XOR is a natural way to combine hashes in this context, because (foo XOR bar) is the same as (bar XOR foo)
<alexgordon>
it still works
<alexgordon>
a XOR b XOR c is the same as c XOR b XOR a. I think :P
<ec>
XOR(XOR(A,B), C) and XOR(A, XOR(B, C)) are the same?
<ec>
what even is the term for that
<ec>
uh
<ec>
transitive?
<ec>
this is a group-thery thing :P
<ec>
no 'cuz exclusive? I think? right?
<ec>
fffff
<alexgordon>
commutative
* ec
is now doing all of his searches for things prefixed with ‘proofwiki’
<alexgordon>
did you see my mathematics.txt I showed glowcoil?
<ec>
that they're trying to make ‘following the order of definitions in <arbitrary math book> by following along with corresponding definitions on ProofWiki’ a thing:
<ec>
“To put it bluntly: anyone can post up mathematics on a website – it's easy. The more challenging aspects are to achieve a consistent style and to ensure a high level of rigor in the context of cross-linking.”
<ec>
I. Like. These. Guys. A. Lot.
<alexgordon>
haha
<ec>
where do I put money
<ec>
do they have a money-hole
<ec>
everybody needs a money-hole
<alexgordon>
probably
<ec>
I want to put money in their money-hole
<alexgordon>
they have twitter, ask them
<ec>
ugh I SHOULD be working on my résumé
<ec>
alexgordon: will you help me on my résumé
<alexgordon>
do that
<ec>
in a bit
<alexgordon>
uhhh
<alexgordon>
it's easy
<alexgordon>
write what you've done
<ec>
after I look at this
<ec>
so I can put in my uni app
<ec>
idk it's not easy I have so much fucking trouble with it
<alexgordon>
if you haven't done anything, make it up
<ec>
that's the hard part :P
<ec>
I love the name btw
<ec>
just love it
<ec>
makes me want to contribute at least 10% more
<ec>
can we keep it Bhāṣā tho, canonically
<alexgordon>
yeah
<ec>
wow, that's atrociously ugly in fixed-width
<alexgordon>
as long as I don't have to type it
<ec>
hahhhhhhhhahah
<ec>
set it up as a completion
* ec
tries to make it prettier with unicode hackery
<alexgordon>
good idea
<alexgordon>
ec: we've got a name crazier than Urbit. Step one complete!
<ec>
ʙʜᴀ̄ꜱ̣ᴀ̄
<ec>
fuck that's *worse*
<alexgordon>
bhāṣā
<alexgordon>
yay substitution works
<ec>
Ｂｈａ̄ｓ̣ａ̄
<ec>
y m i down this
<Hrorekr>
Bhasha?
<Hrorekr>
Name for a new programming language?
<ec>
who is Hrorekr again?
<Hrorekr>
ec, you sent me a book on compilers
<ec>
oh lol hi
<purr>
lol
<ec>
Hrorekr: Bhasa, apparently a framework laid on *top* of a language for handling versioning and implementation-resolution? kinda?
<ec>
a replacement for stuff like `require()` and npm and RubyGems.
<ec>
or alternative to.
<ec>
or aide-to.
<alexgordon>
Hrorekr no no not bhasha, but Bhāṣā ;)
<ec>
lmao
<ec>
ugh that's so ugly in my IRC client. >:
<alexgordon>
ec: it's भाषा in sanskrit if that helps
<ec>
<ec>
IMPROVEMENT
<ec>
but iOS incompatible I'm sure
<ec>
ff.
<Hrorekr>
alexgordon, I know, I'm Indian
<ec>
… and Windows
<ec>
… and Linux, idk
<alexgordon>
Hrorekr: orly!
<ec>
owl!
<ec>
article == ‘package?’
<alexgordon>
ec: article is like the base class
<alexgordon>
everything is an article
<ec>
alexgordon: code/text?
<ec>
what is intention here? why hosting text?
<alexgordon>
documentation!
<ec>
talk to me more about that later
<ec>
reading
<ec>
interesting that you're trying to store documentation in the same system
<ec>
didn't *think* of that, but also not *against* it
<ec>
can we somehow link that into code, though?
<ec>
er, not link, but …
<alexgordon>
think of it like doccomments
* ec
breathes
<alexgordon>
you want the documentation to live as close to the code as possible
<alexgordon>
otherwise they get out of sync
<ec>
can we make them comments or something, and make it a Basic Property of bhasa that *any combination* of Articles can then be mapped into a single text file, and then back?
<alexgordon>
ec: yes indeed, already worked that out. there will be a round-trip representation to source code files
<ec>
because if we *do* store documentation, I want it to map 1-to-1 into in-langauge documentation-blocks.
<alexgordon>
where the text sections are represented as comments
<ec>
ditto discussion: I'd love documentation to optionally be serializable below the function.
<ec>
yah I want as-close-to-code
<ec>
100% agreed 100%
<ec>
okay, but, double-checking,
<ec>
we want this to work pretttttyyyyy seamlessly with existing code, right?
<ec>
so, if I'm mapping things in my head correctly,
<ec>
the existing docstring above a Python function, for instance, maps into a separate article/page?
<ec>
(not against that. actually sounds like a pretty good idea.)
<alexgordon>
eh I dunno, there's so much variation in documentation systems
<alexgordon>
I'm not sure I can get them all to agree
<ec>
don't necessarily have to
<ec>
but if we *support* the most common patterns (i.e. don't actively work against them), then we can swallow up existing code from the Most Languages Possible.
<ec>
right?
<alexgordon>
yeah
<alexgordon>
best effort
<ec>
(just working on my mental model of our intentions/plan, not proposing any changes)
<ec>
k. back to reading.
<ec>
oh wait
<ec>
no
<ec>
totally missed the part where a single *article* has multiple sections
<ec>
can you elaborate on intention of sections? this is like the documentation that goes with a function/package, I get that much
<ec>
but how do you envision having *more* than two sections? or, for instance, two code sections at all?
<ec>
(or two sections in different code-languages)
<alexgordon>
ec: the sections are abstract
<alexgordon>
ec: they don't correspond to code per se, but chunks of code
<ec>
I get that, but I mean in terms of *your* mental model, you're only actively envisioning doc+code right now?
<ec>
or do I mis-understand what the second gist is talking about
<ec>
'allo prophile
<alexgordon>
sup prophile
<prophile>
aight gents
<alexgordon>
ec: each pretty much
<alexgordon>
* yeah pretty much
<ec>
hm
eligrey_ has joined #elliottcable
<alexgordon>
ec: each Article can have opaque code or text sections
<ec>
so you're *thinking* about breaking languages' ‘packages’ down into component parts, a little bit more
<ec>
not treating implementation or tests as opaque blobs?
<alexgordon>
ec: or it can have semantic sections like "impl"
<ec>
(again: not opposed)
<ec>
(just delta'ing thoughts)
<alexgordon>
so there are unsemantic and semantic sections, see?
<ec>
like, if a JavaScript class were done this way, the constructor-function might have its' own section?
<alexgordon>
well I am designing it around functions
<ec>
ooo if you're wanting to do that, it defffffffinitely needs to be nest-able
<ec>
(not in terms of nesting *actual* semantics,
<ec>
but in terms of the format allowing for semantics that are deeper-structured)
<alexgordon>
I should make some examples for you
<ec>
no I get it, reading more now
<ec>
but was just a passing thought: if we're leaving this a little open-ended, then somebody *could* want to have ‘packages’ that are larger than functions, for their environment/language/whatevs.
eligrey__ has joined #elliottcable
eligrey has quit [Ping timeout: 244 seconds]
<alexgordon>
*shrug*
<purr>
¯\(º_o)/¯
<alexgordon>
it's json, so you can do whatever with it
<alexgordon>
I am only interested in functions written in the Bhāṣā language, and in JS
<ec>
so in your second gist
<ec>
you're constructing "version" as a count of a linked-list of "articles"?
<ec>
or wait, of, "sections"
<ec>
because I saw "parent"
<alexgordon>
no no
<alexgordon>
sections are keys
<alexgordon>
articles are objects
eligrey_ has quit [Ping timeout: 244 seconds]
<alexgordon>
so yes, a linked list of articles
<ec>
hm.
<alexgordon>
maybe I should just call them keys and objects lol
<purr>
lol
<ec>
so a change to documentation or, whatever, is a change to the overall thing. we're content-hashing the Whole Thing. makes sense.
<ec>
yeah do that.
<ec>
keys/objects, and then the *interface* treats them as articles/sections
<ec>
(XOR-content-hashing. whatevs)
<alexgordon>
it's just that "object" is such an overloaded term
<ec>
yeah this all makes sense to me
<ec>
so far
<ec>
explain the *object* having a "name" (not as a section, which surprises me.), and each section having a "name" as well
<ec>
idea: let's *ditch* having a name, and use URIs? then the UI-builder / language-implementor can decide how to store-and-extract ‘names’
<alexgordon>
wait which bit
<alexgordon>
objects don't have names, they have uuids and display titles
<ec>
because not all languages even *use* names as a big unique thing: C++, for example, which your example is kind of implying … overloads names inherently, so the *type signature* is really the unique thing to resolve on.
<ec>
yeah the display-title is what I'm saying “let's get rid of.”
<alexgordon>
well you have to have a display title for documentation at least
<ec>
it's unnecessary to the whole plan; it's a hold-over of thinking of these as wikipedia articles
<alexgordon>
ec: also my example is not in C++ it's in Bhāṣā
<ec>
far more useful than displaying “Split” prettily at the top, is displaying `Array split(String)`
<ec>
or whatever else maybe relevant for the language
<ec>
got me?
<ec>
oh that's actually perfect
<ec>
put that *in the object*!
<alexgordon>
that's presentation anyway
<ec>
replace the "name" field, with a "path-to-name" field
eligrey_ has joined #elliottcable
<alexgordon>
ec: no no, the name is just the name
<ec>
hm. talk about it later, but I'm still unconvinced that ‘objects’ (articles) need human-written ‘names’, independent of their function-name/type-signature/whatever
<ec>
I think it'll almost always be duplication. If one is needed, I suspect it should be embedded in the object-type's design
<ec>
but very bikesheddy, so, moving on:
<ec>
“Get the article whose "impl" hashes to …”
<ec>
alexgordon: I don't see an "impl" key above, what does that refer to in that context?
<alexgordon>
god this is tedious to type out by hand
eligrey__ has quit [Ping timeout: 244 seconds]
<ec>
you can just write code if you want :P
<alexgordon>
ec: the name is part of the documentation
<ec>
this is your whole thing, you don't *have* to run it by me
<alexgordon>
call it "recommended name" if you want
<alexgordon>
it's the name at DEFINITION vs name at USE that I was talking about earlier
<ec>
hm. When writing documentation, you very rarely *name* anything, though. you ‘attach’ a bunch of written prose, to a particular element of code
<ec>
and that element has a module-name, or a function-signature, or some other identifier,
<alexgordon>
everything has a name, as a definition, so that you can look at a funciton in one project, and look at it in another project and think THIS IS THE SAME FUNCTION
<ec>
that (for example) documentation-generators extract, with knowledge of the AST, and then display as a title
<alexgordon>
but it's just for guidance purposes only
<ec>
you get me?
<alexgordon>
it's the default
<alexgordon>
um
<alexgordon>
let's build it and see
eligrey_ has quit [Ping timeout: 244 seconds]
<alexgordon>
ec: I can't show you without building it, but the keys are just a convention anyway so ultimately this can be decided later
<ec>
mmmm all of this is bike shedding *to an extent*
<ec>
I'm less interested in the specifics, and more in how they give an indication of the direction?
<ec>
so, let me kinda say all of your stuff in Elliottese, to ensure that I have it; using slightly different words
<alexgordon>
ec: I haven't explained to you my langauge design yet, so you are thinking of everything in JS, which is _fine_, but I am thinking of everything in Bhāṣā language
<alexgordon>
and so I'm wondering how it would be adapted to work in JS
<ec>
hahahah
<ec>
wait confused
<ec>
why are you *also* naming an actual language the same thing
<ec>
anyway, Elliott's:
<ec>
Elliottese:*
<ec>
okay, so I *do* want to talk about naming more.
<ec>
because in my ivory-tower design mind, I'm still stuck on ‘mapping intent to (name-and-implementation)’; and I'm not sure my concerns about naming have been involved. or I'm not clear how, I mean:
<ec>
so you have a “display name”, but that's not something to *map* on;
<alexgordon>
think of it as a database of functions
<ec>
and now, ‘the name of a thing’, in terms of how we look it up, retrieve it, map it to a content hash, has kind of expanded
<alexgordon>
each function has a default name, and a rowid (the uuid)
<ec>
because if we're talking about C++ and JS and your new language work, it can be faarrrr more useful to talk about the type signature or something
<alexgordon>
when you import the function, you say "I want function <uuid> to be imported as <name>"
eligrey has joined #elliottcable
<ec>
I need to come back later
<ec>
but I think this is really, really important D:
<alexgordon>
kk
<alexgordon>
the name doesn't have any significance to me
<alexgordon>
it's just documentation
<ec>
see, if you implemented this as `require('uuid')`, that wouldn't be much of an issue; but this is an area where the user-interface Really Matters