<whitequark>
1) it crashes 2) it's *impossible* to deploy
<whitequark>
like you need to hate your users with a passion and a sadistic enjoyment to make them install ruby-qt apps
<devyn>
wellllll, I just need something that works well enough for a prototype, and I think probably I won't do most of it with qtbindings
<devyn>
in fact I'm interested in trying QML
<devyn>
and just binding the QML to my Ruby backend via qtbindings
<devyn>
(I already have the Ruby backend, which is why, so that's already difficult to deploy, and there are other things that are difficult to deploy too, so a few extra things don't really matter)
<devyn>
lol
<purr>
lol
<whitequark>
QML is somewhat nicer
<whitequark>
it's still goddamn javascript, but even I admit that it lies in some local minimum of horribleness
<whitequark>
and binding Qt's immensely complex structure directly is definitely stepping far out of that local minimum
<devyn>
whitequark: it pretty much comes down to this or JRuby+Swing, and I think Qt is a better user experience
<devyn>
whitequark: honestly all I want is Shoes but that's a total mess now unfortunately
<whitequark>
aww
<whitequark>
I tried to join shoes just before _why vanished
<devyn>
it was absolutely awesome
<devyn>
and they've tried so hard to maintain it
<devyn>
but _why's code wasn't really very good
<devyn>
it was very… hacky, as usual
<devyn>
and so I think they've had enough trouble keeping classic shoes working
<devyn>
that they've been developing new Shoes from the ground up with the same API
<devyn>
but the problem is that the most advanced one, Green Shoes, is GTK
<devyn>
and GTK on OS X is way worse than Qt
<devyn>
whitequark: oh, wait, good news, looks like I forgot to check the mailing list, they actually just released a Shoes 4 “preview” on May 10th which is JRuby+SWT based
<glowcoil>
devyn: i was just thinking today about how i really want tempus to be accessibly in _why's way
<glowcoil>
devyn: some whimsical literature and really fun stuff
<glowcoil>
devyn: like, i plan to make it like an ideological vm with abstractions that allow you to manipulate everything low level you want but not in a way that breaks any useful type/purity style things
<glowcoil>
devyn: which i am convinced is very possible
<glowcoil>
devyn: so i want visual programming tools that are as privileged as textual tools, and the first ones will be specifically for game dev
<whitequark>
(convinced) cute
<whitequark>
there's been some relevant haskell link recently
<whitequark>
they use insane amounts of magic to keep safety, like, dependent types in every hole
<glowcoil>
devyn: and i'll have really whimsical books for kids to learn the visual tools, but since the abstractions are all like, dropdownable, you can easily just like progressively move deeper
<whitequark>
and it still sucks horribly
<glowcoil>
whitequark: ok well hopefully this will sound less cute and horrible to you
<glowcoil>
whitequark: i'm framing types as like, a lens (no not those lenses) to interpret and manipulate bits
<whitequark>
the issue is invariants depending on the bits themselves
<glowcoil>
so like, some bits can inhabit a type, or not inhabit a type; and the type also basically specifies the primitive operations on them
<glowcoil>
so like abstract data types, except not abstract
<glowcoil>
whitequark: how do you mean
<whitequark>
so you either need to prove that the invariants hold while going from one type to another
<whitequark>
or, hm
<whitequark>
well that's the only way
<whitequark>
well say, you have an ADT defined somewhere, it says "first 4 bits are 0000, 0010 or 0100"
<glowcoil>
ok
<whitequark>
then if you want to interpret that in some way other than just that ADT, you have to preserve that invariant
<glowcoil>
well you see
<glowcoil>
the way i want to do it is very inductively
<glowcoil>
so like, you have haskell-style adt constructors
<glowcoil>
and the invariants are kind of implicit in that?
<glowcoil>
like, the allowed constructors and allowed operations basically comprise the invariants
<glowcoil>
so well typed programs can only be composed of valid operations
<glowcoil>
hm i guess if they are bits and you can cast to like, a bitstring, that won't cut it
<whitequark>
well what is low-level in that?
<whitequark>
exactly
<glowcoil>
ok i'll think about this deeply
<whitequark>
just specifying the representations isn't really too useful
<glowcoil>
but i think it's a useful system
<glowcoil>
the thing that's low level is like
<glowcoil>
you can do bitfield-style specifications
<whitequark>
well it may be useful, but I don't think it's possible outside something like
<whitequark>
Idris
<whitequark>
and it's a fucking pain
<glowcoil>
the way i imagine it you aren't constantly proving theorems, you're just writing types and then functions about them
<glowcoil>
so if idris is dependent types then this wouldn't really be like that hopefully
<whitequark>
well theorems aren't going to prove themselves
<glowcoil>
lol well if they're all for free based on the structure of your code
<purr>
lol
<glowcoil>
and you don't allow some theorems to be expressed i guess
<glowcoil>
like most type systems, including most dependent type systems
<whitequark>
... I think you're up for a very disturbing revelation
<glowcoil>
i mean, i probably don't want to *allow* variants such as "this graph, expressed using internal pointers, is acyclic"
<glowcoil>
ok so
<glowcoil>
if you give a list of operations that preserves the property of being acyclic
<glowcoil>
then downcasting from a bitstring
<glowcoil>
could possibly fuck you over and now you have like, theorem proving to do
<glowcoil>
so i have a hunch that i can do something like paws' insanities
<glowcoil>
must think more
<glowcoil>
but basically i want to sidestep mathematical purity here
<glowcoil>
and avoid theorem-proving, and allow some runtime errors as the cost i pay for having a fast, intuitive, mechanistic type system
<glowcoil>
so, i think you have the idea that i'm proposing something like,
<glowcoil>
you write mathematical statements about your types and that's the definition
<glowcoil>
and the compiler magically verifies them
<glowcoil>
and that is not at all what i'ma bout
<glowcoil>
about
<whitequark>
well so what do you do, you basically typecheck stuff manually on access?
<whitequark>
rather than proving properties via type system for the program, you make the runtime prove properties for values?
<whitequark>
geez that would suck so hard
<glowcoil>
i have no idea
<glowcoil>
i might allow:
<glowcoil>
unsafe downcasting, where unsafeness is quarantined/rollbackable via insanities
<glowcoil>
or some shit
<glowcoil>
like, it's better than in java where you literally just have explosions when you downcast bad things
<glowcoil>
i have said, i want to allow some things to go wrong as a compromise for having a useful type system
<glowcoil>
i am no longer a fan of dogmatic math applied to real, executable systems
<glowcoil>
math should know its place when applied to a computer
<glowcoil>
whitequark: see, the reason i want every type to imply a binary representation for every value is so that everything's serializable
<glowcoil>
by default
<glowcoil>
like some things are very large and it's a bad idea to serialize, but i want people to be in the mindset of values being easy to pass over the network and interpret unchanged, rather than pretty-printing and parsing at every network transfer
<glowcoil>
and it's a lot of work to set up a system to do this for games
<glowcoil>
online games are an example of where this is done because text is unacceptable at that level of realtime requirements
<glowcoil>
so if it's like, implicit in the entire type/value system/model
<whitequark>
all the HTML5+JS games look at you with contempt
<whitequark>
automagic serialization sucks, because cycles
<glowcoil>
i guarantee you that real-time multiplayer games in html5 and js find a way that is not so parsey
<glowcoil>
cycles?
<glowcoil>
and i want to make it automagic but *very* tweakable, through a system of directives kind of like bitfields but way better
<glowcoil>
what do you think of that
<whitequark>
I think you're solving a problem which does not exist, and the solution is probably plain out impossible
<glowcoil>
ohhhh graph cycles
<glowcoil>
?
<glowcoil>
i'm thinking of making graphs tend to be represented through internal pointers?
<glowcoil>
or adjacency ____s
<whitequark>
btw, have you seen cap'n proto?
<glowcoil>
yes
<glowcoil>
it seems like a great tool i might use someday but very specific and knows its place, whereas i want to design a programming language
<glowcoil>
haha i followed the language design work of the guy who went to google and made protobufs
<glowcoil>
just a fact
<glowcoil>
but yeah capn proto is like what i want but very specific
<glowcoil>
actually i could probably learn some good lessons from it; going to study it
<whitequark>
well do take a look
<glowcoil>
ohhhh the guy, whose language shit i followed, is kenton varda
<glowcoil>
who made capn proto
<glowcoil>
cool
<whitequark>
yea
<glowcoil>
same guy
<glowcoil>
see, capn proto seems *very* similar to my ideas for tempus' data model
<glowcoil>
so now i've gained confidence
<glowcoil>
a little bit
<glowcoil>
:p
<glowcoil>
shittt i should sleep
<glowcoil>
i think it's not obvious to a lot of people why i follow them on twitter but i usually have a really specific thing that they did that i follow them because of
<glowcoil>
also it boggles my mind that some people use google+ in their real lives
<glowcoil>
ok, segments are a thing i should have thought of and didn't
<glowcoil>
whitequark: tell me your thoughts on the decision to restrict data topology to trees
<whitequark>
lol what
<purr>
lol
<glowcoil>
is it just like
<glowcoil>
Consistently Good Things
<whitequark>
graphs are like
<glowcoil>
(capn proto did it)
<whitequark>
the most important thing in online games
<glowcoil>
ok so you'd basically just end up embedding graphs in the trees anyway
<whitequark>
well yes, you can interpret arbitrary DCG as a DAG and a set of backedges
<whitequark>
the hard thing is detecting those backedges
<whitequark>
you could distinguish them in the typesystem like rust does with RcWeak and RcStrong
<glowcoil>
no what i meant was that you'd probably make higher level adjacency ____
<glowcoil>
whitequark: oh interesting
<glowcoil>
c abstracts over endianness for most applications and then you can drop down with bitwise to detect it
<glowcoil>
whitequark: is that a true statement
<whitequark>
no
<whitequark>
c does absolutely nothing to abstract endianness
<devyn>
it's actually just rc::Rc and rc::Weak now IIRC
<glowcoil>
whitequark: i just mean that + and - will work the same regardless
<devyn>
and then several other modules also have Weak types
<glowcoil>
whitequark: so you don't have to rewrite that part
<whitequark>
i.e. you're as far from any endianness detail in c as in assembly
<glowcoil>
ok so i guess, cpu instructions abstract it in that way then lol
<purr>
lol
<whitequark>
they... *have* endianness
<whitequark>
they don't abstract it
<whitequark>
endianness is how bytes are laid out in memory. instructions work mostly with registers
<whitequark>
so really, the only time when you encounter endianness is when you put something into memory and then read it as another type
<whitequark>
anotherly sized type
<glowcoil>
right
<glowcoil>
ok
<devyn>
yeah you won't notice endianness with bitwise operations
<glowcoil>
starting to think that i need more segregation between the low-level capable parts of tempus and high-level-niceness parts, i.e. 2 languages
<devyn>
you will if you cast int * to char * though for example
<glowcoil>
don't worry, i already want to embrace multiple languages on the same vm since i want some visual ones
<glowcoil>
i just want very good interop, so you can drop down
<glowcoil>
devyn: ohhh right bitwise shift down wouldn't detect
<glowcoil>
ok that makes sense
<whitequark>
oh god yet another guy with a milti-language vm
<devyn>
glowcoil: yeah, bitwise is entirely within whatever the word's bounds are
<glowcoil>
lol it's not for other people to write languages on
<purr>
lol
<devyn>
so endianness doesn't matter
<glowcoil>
it's for me to write a game tool to run games on
<glowcoil>
that's hopefully more useful to experts than game maker and construct
<glowcoil>
because you can continue to use it once you need low level tweaks
<glowcoil>
so i'm not emphasizing that it's a vm
<glowcoil>
i'm emphasizing that it's several ways to write code, that play nice with each other
<glowcoil>
anyway why am i defending my ideas to you, you'll never use it
<devyn>
hmm
<glowcoil>
i have a target audience in mind and it will be useful to them
<glowcoil>
and i can resolve design problems in my own head too
<devyn>
now you've got me thinking… I wonder if it's possible to write a nice reactive code generator with Rust macros
<whitequark>
there's been a guy on #ocaml who wanted a lang to make games in
<whitequark>
he had syntax like
<whitequark>
a mix of lisp and significant indentation
<whitequark>
how fucking high do you need to be
<glowcoil>
lol
<glowcoil>
well first of all i'm bored by the very mention of that idea but also i think you'll probably think tempus is dumb so i won't go seeking self esteem boosts from you about it
<glowcoil>
and i'm very confident that it will be useful and satisfying to me, and to a target audience
<glowcoil>
so
<glowcoil>
:p
<whitequark>
I simply think you aren't going to succeed *shrug*
<purr>
¯\(º_o)/¯
<whitequark>
not because you or your ideas are dumb, but simply because they're internally conflicting
<whitequark>
I mean, you're far, far from the first person to attempt a multi-language VM, it never ever worked
<whitequark>
there's PyPy and to some degree Truffle, but PyPy is a "VM construction framework", it doesn't aim at coexistence
<glowcoil>
i don't aim at coexistence either
<whitequark>
and with JVM/.NET, anything you build looks like sh^WC#
<glowcoil>
is the problem with what you're saying
<glowcoil>
i'm not making
<glowcoil>
a vm
<glowcoil>
like jvm and .net or fucking parrot
<glowcoil>
pypy is entirely made to compile python
<whitequark>
wat?
<glowcoil>
like, pypy is called "an implementation of python"
<glowcoil>
not "a vm to implement your fun new language on"
<whitequark>
pypy is an awesome vm construction framework and it supports ruby (topaz) on a completely first-class basis
<glowcoil>
i believe you
<whitequark>
I don't give a fuck how it's called, I've seen its architecture and talked with authors
<whitequark>
it's like, designed to provide common runtime support, such as OSR or GC, for a very wide class of languages
<glowcoil>
and i don't know the founders of pypy but until this moment i would have believed it supported other languages because it's well architected but all i knew was that it was an exceptionally modular and efficient way to compile python
<whitequark>
sort of like LLVM would work for different compilers if it had *extensible* IR
<whitequark>
which is actually a major deficiency of LLVM, LLVM is basically a C compiler middle-end and back-end
<glowcoil>
and i mean, look at _why's unclean, compiling ruby to the old python vm
<glowcoil>
so
<whitequark>
like JVM is designed to run fucking Java and everything you run on JVM turns into Java
<whitequark>
_why's unholy
<glowcoil>
right
<whitequark>
and it doesn't actually run ruby
<whitequark>
just a ruby-like thing
<glowcoil>
right, that's not really relevant, the point is that every interpreter is a vm on some level
<glowcoil>
and i said tempus is a vm and i regret doing that in your presence
<glowcoil>
so i'm now going to look at pypy to learn from it, but there's a limit to how applicable it will be because tempus is kind of a fundamentally different way to structure programs and a vm aimed at a language with a GIL in it is bound to be ill suited to tempus
<whitequark>
I don't think PyPy takes advantage of, or requires, GIL
<glowcoil>
right i didn't mean anything detailwise
<glowcoil>
i just meant that python is violently, oppressively sequential
<whitequark>
ugh
<whitequark>
don't be quick to dismiss pypy
<whitequark>
I did that mistake
<glowcoil>
oh i'm not being quick to dismiss, did you hear me just say i want to know everything worthwhile about it so that i can learn from it
<whitequark>
"a vm aimed at a language with a GIL in it is bound to be ill suited to tempus
<whitequark>
you are
<glowcoil>
like, i will take that statement back if i learn that in fact pypy is good at running tempus, and i can imagine making the decision to compile tempus to pypy
<glowcoil>
i'm simply doubting it
<glowcoil>
i have plans for the tempus bytecode that are well suited to its program structures
<glowcoil>
and i simply doubt that a vm designed for a language that used to run on a stack based vm, and has a gil, will not require some backflips in compilation
<glowcoil>
i mean he's reacting to the smugness of haskellers which is somewhat justified
<glowcoil>
but i hate him all the same
<whitequark>
then don't fucking read it
<glowcoil>
fuck you for saying that, that's so stuipd
<glowcoil>
i can react to other people's opinions
<glowcoil>
that's literally what talking is
<glowcoil>
also, what do you know, a retweet of a haskell-positive tweet a little bit down on his timeline, so now i'm slightly humbled
<whitequark>
also I don't think that article is smug actually
<glowcoil>
how about YOU don't fucking read my messages about him in here if that's your reaction to them
<glowcoil>
anyway
<glowcoil>
why not
<whitequark>
" A less blatant violation is that the equational theory of the language with seq is different from the equational theory without it, and the last I knew the GHC compiler was willing to make transformations that are valid only in the absence of this construct. "
<whitequark>
which is like
<whitequark>
C does this because it's fucking C
<glowcoil>
right i hate seq but i think purely functional languages without trapdoors are ill suited to running on sequential cpu archs
<whitequark>
are ill suited for real world
<glowcoil>
also i more hate existential type when he gets smug about how "typed languages are strictly more powerful than dynamic languages because those have only one type"
<glowcoil>
whitequark: right, i have to concede that
<whitequark>
because they pretend that hardware is literally infinite and that's simply not true
<glowcoil>
right i agree
<glowcoil>
that's why i want tempus not to take that attitude
<whitequark>
oh he is absolutely right to be smug about it
<whitequark>
because it's true
<whitequark>
:p
<whitequark>
it's just that, like
<glowcoil>
"strictly more powerful" is the dumbest fucking phrase you can say about programming languages whatsoever
<whitequark>
with more power comes more hassle
<glowcoil>
unless you are talking about how c is strictly more computationally powerful than agda given infinite resources
<glowcoil>
because that's a well defined notion of powerful
<glowcoil>
whereas "having a type system" is not a well defined notion of poweful
<whitequark>
say Coq is strictly more powerful than OCaml but it is also such a fucking pain
<glowcoil>
no, coq can express fewer programs since they must halt
<glowcoil>
thus strictly less powerful
<whitequark>
use fuel
<whitequark>
for example
<glowcoil>
oh i guess gallina
<glowcoil>
fuel?
<whitequark>
gallina?
<glowcoil>
so wikipedia says "coq implements gallina; gallina is strongly normalizing"
<glowcoil>
so maybe coq *is* turing complete
<glowcoil>
but whatever
<whitequark>
well, if you say that "powerful" is "can prove more statements about the program"
<whitequark>
which is a very useful notion of "powerful"
<whitequark>
then it's true
<glowcoil>
sure though you really mean to say "a robot will prove more statements about"
<glowcoil>
which is certainly useful, i enjoy robots performing labor for me
<whitequark>
disagree
<glowcoil>
how so
<glowcoil>
/ with what things
<whitequark>
in light of code not written by you, a stronger type system realistically enables a human to reason about code better
<whitequark>
like, say, ruby
<whitequark>
p 2 + 2
<glowcoil>
right, dealing with foreign code is something
<glowcoil>
i concde
<whitequark>
you have no fucking idea what that will ever execute unless all of the code that's currently loaded is written by you
<glowcoil>
concede
<glowcoil>
though, you can verify that pretty damn quickly, and also there are lots of social signifiers about libraries that tell you whether they will override p, 2, or +
oldskirt has joined #elliottcable
<glowcoil>
though that only goes so far when you have activerecord, i understand
<glowcoil>
whitequark: so does pypy do something kind of like asm.js for the restricted subset of python the self-hosting thing is in?
<glowcoil>
like, not so horrifying, but yeah?
<whitequark>
OH GOD NO, DON'T FUCKING EVER MENTION ASM.JS
<whitequark>
and no, you're not correct
<glowcoil>
ok
<whitequark>
rpython is basically "something like C but with python syntax and other small niceties"
<whitequark>
but at its heart it's a c-like thing
<whitequark>
rpython is not interesting
<whitequark>
what's interesting is the optimization capabilities of pypy
<glowcoil>
ok, CPython and PyPy are stack-based virtual machines, i.e. they don’t have registers but instead push object to and pull objects from a stack.
<glowcoil>
according to docs
<glowcoil>
i will continue studying pypy for cool facts BUT i don't think it is well suited for tempus at all
<whitequark>
I suggest you read a paper because I've another conversation right now
<whitequark>
well
<glowcoil>
ok
<glowcoil>
whitequark: rpython runs on cpython though, right?
<glowcoil>
which is the cool part?
<glowcoil>
well i mean not really the cool part
<glowcoil>
but is that a fact
<whitequark>
*facepalm*
<whitequark>
no
<whitequark>
ok I really don't have time to hand-hold you through it right now
<glowcoil>
i mean you never want to
<whitequark>
so later
<glowcoil>
by "runs on cpython" what i meant is
<whitequark>
or just read the paper
<glowcoil>
"is python"
<glowcoil>
i'd rather the docs hand hold me because they're less unnecessarily snarky about it
<glowcoil>
so i'll do that
<glowcoil>
devyn: oh wow whymirror/unholy is forked from devyn/unholy
<glowcoil>
devyn: you got around in the _why times
<glowcoil>
:p
<glowcoil>
and yes my idea about rpython was entirely correct, whitequark, i was simply bad at expressing it
<glowcoil>
the Gateway
* glowcoil
raises eyebrows in approval of PyPy
<glowcoil>
night for real
sharkbot has quit [Remote host closed the connection]
sharkbot has joined #elliottcable
inimino has joined #elliottcable
yorick has joined #elliottcable
inimino has quit [Read error: Connection reset by peer]
Sgeo has quit [Read error: Connection reset by peer]
alexgordon has joined #elliottcable
<glowcoil>
how are my favorite pals on the internet