<cuttle>
devyn: kind of tired of all the css stuff, it's one of those things where you *can* but it's questionable if you *should* :p
<devyn>
cuttle: the point is that you can, not necessarily that you should :p
<cuttle>
lol I'm glad we agree
<purr>
lol
<devyn>
cuttle: I want more pointless artsy things like demoscene
<devyn>
things that are really impressive but useless
<joelteon>
yeah it's a really cool thing that we'll be able to use in 2018
<devyn>
joelteon: what is? lol
<joelteon>
the water loading text
<devyn>
meh, you can always just say fuck everything that's not IE 11
<devyn>
IE-wise
<devyn>
:p
<devyn>
MS thinks IE11 is good enough that they even changed the User-Agent to not mention IE anywhere
<devyn>
instead it's Trident, and like Gecko
<joelteon>
wooow
<joelteon>
ok
<joelteon>
good job internet exploder
<joelteon>
so docker is cool
<devyn>
we can hope that one day IE will be perfectly in line with WebKit & Gecko
<joelteon>
apparently docker makes continuous deployment really fast
<devyn>
seems like MS's strategy for backward compatibility lately is just to include all of the older engines and only trigger them when it recognizes old things
<devyn>
<!DOCTYPE html> seems to be enough to trigger edge mode lately
<joelteon>
good thing they're so committed to backwards compatibility
<devyn>
they have to be... but this way at least they're not stuck
<devyn>
they can have an actually modern engine that doesn't support any legacy IE stuff
<cuttle>
devyn: demoscene is a good comparison, I guess
<cuttle>
I relent, CSS stuff is cool
<joelteon>
the biggest problem with compiled languages is the "compiled" part
<joelteon>
:(
eligrey has quit [Quit: Leaving]
<devyn>
cuttle: yes, I want nouveau-demoscene
<devyn>
I mean the people optimizing insane 3D animations into tiny, tiny executables are awesome,
<cuttle>
joelteon: haha what
<devyn>
but... that doesn't have to be the only thing
<joelteon>
it's
<cuttle>
devyn: yeah good point
<joelteon>
instead of deployment being
<joelteon>
"git pull"
<joelteon>
and restart unicorn
<joelteon>
you pull, then you have to compile it again
<cuttle>
/me nods
<joelteon>
i'd be fine with compiling again except
<joelteon>
for the whole
<joelteon>
"memory" thing
<cuttle>
wait what
<joelteon>
ghc creates object files that make ld use a lot of ram
<joelteon>
more than my poor little DO box can afford
<cuttle>
oh ok
<joelteon>
so i have to build in a VM and copy the built binary
<cuttle>
jesus
<cuttle>
:p
<joelteon>
docker will fix that
<joelteon>
not fix it exactly
<joelteon>
but make it less painful
<joelteon>
not make it less painful, really
<joelteon>
since i'm still using a VM
<joelteon>
so there's no point to doing it
<joelteon>
well
<joelteon>
I could build a CI server that does it
<joelteon>
but then again I could just build a CI server that does the copy and the restart
<cuttle>
hahaha that was a lot of second guessing every single thing you said
sharkbot has quit [Remote host closed the connection]
<devyn>
I don't think that's crazy; I think that's awesome
<devyn>
but
<devyn>
the crazy part of it all is
<devyn>
What is %brts? The atom also known as 1937011298 or 0x73747262. Simply a string mapped to an unsigned integer, LSB first. It’s easy to see why the vowels got lost - %bartis is 126896762413410 or 0x736974726162. On a 32-bit CPU with 31-bit direct atoms, %brts is direct and %bartis indirect (not that the programmer can tell the difference). But you still say “bartis.”
<devyn>
BECAUSE FITTING SYMBOLS INTO A PROCESSOR REGISTER IS TOTALLY A GOOD REASON
<yorick>
devyn: my fear is that 4-char strings fit inside 32 bits
<devyn>
yorick: 4-char strings fitting in 32 bits is reasonable if each char is only a byte...?
<yorick>
yes
<devyn>
so...?
<devyn>
this obviously isn't a language that cares about Unicode
<cuttle>
buzzwords held together by function words
<cuttle>
ok so, idea:
<cuttle>
a program is a big ol list of facts
<cuttle>
some define parts of a data type
<cuttle>
some define parts of values
<cuttle>
so you might say
<cuttle>
true : bool
<cuttle>
false : bool
<cuttle>
now you have two bools
<cuttle>
you might say
<cuttle>
f(true) = 3
<cuttle>
f(false) = 4
<cuttle>
now f is fully defined on bools
<cuttle>
you could say
<cuttle>
f : bool -> number or whatever
<cuttle>
not sure how i'm going to differentiate between type annotations and data declarations, maybe just a data keyword or some shit
<cuttle>
anyway
<cuttle>
you can also say like
<cuttle>
velocity = integral(acceleration)
<cuttle>
position = integral(velocity)
<cuttle>
and when you say =, something is true forever
<cuttle>
but for instance you can say things like
<cuttle>
not sure what the syntax would be, but you could write a line of code that states that velocity is incremented by 3 per unit time
<cuttle>
and then you could write another line of code that coexists with that, and each thing happens at the same time and they're combined togehter
<cuttle>
imagine applying several forces to a physical object
<cuttle>
another example could be
<cuttle>
a line specifies, when this particular event fires/this value changes to this, then this value changes to that
<cuttle>
or, a line pushes a thing to a queue
<cuttle>
basically, lots of things are good at accumulating influence from a lot of sources
<cuttle>
like for instance stdout is a queue you push strings to
<cuttle>
or the screen is something you push image-drawing commands (an image and a position to draw it at or something) to
<whitequark>
cuttle: so the language would essentially be a constraint solver
<whitequark>
reminds me of prolog somewhat
<whitequark>
the problem is that it's very very easy to write a completely undecidable problem that way
<cuttle>
whitequark: no, it's completely deterministic
<cuttle>
no solvers
<whitequark>
mhm
<cuttle>
hm, i guess some things could clash
<cuttle>
like, if you had two conditions specifying contradictory states of a variable
<cuttle>
and the conditions were potentially overlapping, you'd need halting problem etc.
<whitequark>
exactly
<whitequark>
I mean I think this kind of stuff is very cool, but it's also very hard and unpractical
<whitequark>
the "simple problems in C become PhD topics in Haskell" catch
<cuttle>
well i could limit the conditions to patterns
<cuttle>
you can deterministically say whether all patterns have been matched
<whitequark>
yup, but also pattern matching in... every langauge I know has those 'when' clauses
<whitequark>
or, well, just conditionals
<cuttle>
yes of course
<cuttle>
there will be conditionals too
<whitequark>
how'd you handle that?
<cuttle>
well
<whitequark>
I'm afraid you will end up in the haskell route, aka "let's complicate our type system until it can express everything... oh wait, no, let's just complicate it until we have no idea how it works"
<cuttle>
restrict the multiple definitions that can make up a single value to patterns
<cuttle>
for more complex conditions it has to be in an expression
<whitequark>
okay
<whitequark>
so what do you do if two expressions conflict?
<cuttle>
?
<cuttle>
what do you do if the if and else clause in haskell or ruby "conflict"
<cuttle>
that's what i'm taling about with expressions
<whitequark>
ok
<whitequark>
so you basically limit data flow with your pattern matching sublanguage
<whitequark>
or can you express everything you can express with patterns, with just expressions?
<cuttle>
patterns are for like
<cuttle>
polymorphism
jvulc|znc has quit [Ping timeout: 240 seconds]
<cuttle>
turing complete wise you can express everything with expressions
<whitequark>
gimme examples
<whitequark>
in code
<cuttle>
ok
<cuttle>
type move
<cuttle>
rock : move
<cuttle>
paper : move
<cuttle>
scissers :move
<cuttle>
game(paper, rock) = paper
<cuttle>
game(rock, scissors) = rock
<cuttle>
game(scissors, paper) = scissors
<cuttle>
game(a, b) = game(b, a)
<cuttle>
exhaustive patterns
<whitequark>
isn't this like
<whitequark>
prolog?
<cuttle>
deterministically verifiable
<cuttle>
not really
<cuttle>
there's no searching to satisfy constraints
<cuttle>
this is just normal old functions
<cuttle>
it's like if you said in haskell
<whitequark>
oh ok
<whitequark>
I see
<cuttle>
game a b = case a of { ... }
<whitequark>
ok so
<whitequark>
what's the point?
<cuttle>
in fact i got the idea for an RPS game from Atomo
<cuttle>
well, you could do this:
<cuttle>
gun : move
<cuttle>
somewhere else
<cuttle>
and then write
<cuttle>
game(gun, x) = gun
<whitequark>
so extensibility
<cuttle>
yeah
<cuttle>
so the problem with OO hierarchies is that
<whitequark>
seems like some kind of awkward special case
<cuttle>
you can add new cases of a datatype
<whitequark>
maybe it's not
<cuttle>
but you can't add new operations
<cuttle>
(barring monkeypatching)
<cuttle>
the problem with haskell data types is
<cuttle>
you can add as many operations as you want
<whitequark>
refinements?
<cuttle>
but not new cases to a data type
<cuttle>
so this lets you both add new operations and add new cases of a data type
<cuttle>
freelly
<cuttle>
sure, refinements are a solution
<cuttle>
and c# util classes
<whitequark>
also
<cuttle>
and go and rust's methods and stuff
<whitequark>
your thing is equivalent to monkeypatching
<whitequark>
totally
<cuttle>
well it's scoped
<whitequark>
what if a value escapes?
<cuttle>
if you import a module that uses types that aren't available to you it'd be an error
<whitequark>
so you can extend it but cannot use it in unextended modules?
<whitequark>
why would you want to extend it then?
<cuttle>
doesn't that stand to reason?
<cuttle>
look at this
<cuttle>
you have a data type
<cuttle>
people are using it happily
<cuttle>
you want to extend it in your project
<cuttle>
so you don't have to break open the library, you just write a module that extends it, and your project uses that module
<cuttle>
but other projects don't
<cuttle>
why would it ever make sense to have an extended data type where using operations on it is just an error
<whitequark>
well
<cuttle>
basically, it's statically verified that all operations in the scope you're running in have code for every case of a data type
<cuttle>
and if they don't it's an error
<cuttle>
and the scope can come from imports
jvulc|znc has joined #elliottcable
<whitequark>
ok, so
<whitequark>
do you have closures?
<whitequark>
any indirect call mechanism, for that matter
<whitequark>
#send, etc
<cuttle>
probably will have first class functions
<whitequark>
ok
<whitequark>
so you want to have statically checked safety for your data type extension
<whitequark>
this means that you need to enrich the function signature with its scope
<whitequark>
basically, the module it came from, or, in a more flexible way, its set of imports
<cuttle>
a closure has to have its entire originating scope available
<cuttle>
that's nothing new
<whitequark>
available?
<whitequark>
define available.
<cuttle>
available to the containing code
<cuttle>
the literal definition of a closure
<whitequark>
nono, what I mean is
<whitequark>
say module A defines a datatype and a function operating on it accepting a closure
<whitequark>
module B extends this datatype and passes a closure to module A
<whitequark>
if you want this to be statically rejected, you need to encode the fact that the closure expects the datatype to be extended in its signature
<whitequark>
see?
<cuttle>
ok
<whitequark>
this can cause ripple effects in some cases
<cuttle>
that's less
<cuttle>
encoding information in the closure, and more encoding information in the return type/argument types of the closure
<cuttle>
it's really irrelevant to whether it's a closure
<whitequark>
mhm
<whitequark>
yes, probably
<whitequark>
ok so
<whitequark>
another thing
<whitequark>
you'll have subtyping relation between unextended and extended datatype right?
<cuttle>
i guess so
<whitequark>
what about passing stuff the other way?
<cuttle>
error?
<whitequark>
what when you need it?
<whitequark>
so you import some lib, extend its type, now you cannot use any of the functions it has?