ChanServ changed the topic of #elliottcable to: laser printers are fucking awesome
Sgeo has joined #elliottcable
vil_ has joined #elliottcable
inimino has quit [*.net *.split]
vil has quit [*.net *.split]
<alexgordon>
whitequark: what's the drinking age in russia?
<alexgordon>
is it older than UK? 10?
inimino has joined #elliottcable
<whitequark>
alexgordon: I think it's either 16 or 18
<alexgordon>
18 according to wiki
<alexgordon>
I lol'd at "Until 2011, any drink with ABV under 10% was not considered an alcoholic beverage"
<purr>
lol
* alexgordon
gives purr booze
<whitequark>
yeah both beer and vodka from 18
* purr
rrr
<alexgordon>
purr: that's right
<whitequark>
(until 2011) yeah, you could buy beer and that evil shit which is basically shitty beer+shitty redbull at any age
<whitequark>
alexgordon: why do you ask?
<alexgordon>
[23:36:26] <+whitequark> "Note also that these policies make it possible for fraternities to be the one industry in the country in which every aspect of serving alcohol can be monitored and managed by people who are legally too young to drink it."
<whitequark>
um, well, yeah? that's said about US
<alexgordon>
I know, was just curious
<whitequark>
there's no such college culture around booze in RU. if you want to get drunk at 14, it's not exactly hard
PLejeck- has quit [Ping timeout: 265 seconds]
<alexgordon>
apparently you CAN buy alcohol in yemen "Exception is in Aden Region where it's legal for 21 and up" lol
Willox has quit [Ping timeout: 272 seconds]
<whitequark>
I mean, obviously students (uni & HS_ go and get shitfaced, there's just no need in fraternities to enable that and it's not a huge achievement to be able to do that
<whitequark>
btw, you just reminded me of a fun legal loophole here
<alexgordon>
if you want booze, go to yemen?
<whitequark>
you can't buy alcohol from 23:00 to 08:00, however there are services which deliver it via internet
<alexgordon>
LOL
<purr>
LOL
<whitequark>
of course legally they can't get that, so they do it in a shrewd way: they sell a really expensive, say, lighter
<whitequark>
and as a *gift* they give you a bottle of alcohol
<whitequark>
*that* is apparently legal
<whitequark>
(yemen) why?
<whitequark>
if you want booze, ask someone older to buy it for you
<whitequark>
stranger on the street, relatives, parents, whoever would agree
<alexgordon>
or just buy it myself
PLejeck has joined #elliottcable
<whitequark>
nah, you'd get asked ID in most of places
<whitequark>
that didn't used to happen, but for a few years it does and afaik mostly works
<whitequark>
at least there's hordes of pissed off middle schoolers on the internet
<alexgordon>
so I'd show them my ID
<alexgordon>
I guess we're not actually talking about me ;)
<whitequark>
you'd have to look similar to the photo
yorick has quit [Read error: Connection reset by peer]
<whitequark>
also by ID I mean passport, and fake passport is not exactly easy to obtain
<whitequark>
I didn't really investigate it (why would I?), but I never heard of anyone pulling that just to buy booze
<alexgordon>
no, real ID
PLejeck has quit [Ping timeout: 272 seconds]
jesusabdullah has quit [Ping timeout: 260 seconds]
jesusabdullah has joined #elliottcable
prophile has joined #elliottcable
PLejeck has joined #elliottcable
<joelteon>
ghc 7.8 sucks dick so far
jesusabdullah has quit [Ping timeout: 248 seconds]
<prophile>
joelteon: what problems?
<joelteon>
major performance regressions
<joelteon>
but it's not officially out yet
<joelteon>
I guess that's to be expected
<alexgordon>
glowcoil: around? I had an epiphany
<alexgordon>
prophile!
<prophile>
alexgordon!
<alexgordon>
prophile: it's unusual for us to talk so early in the night
<prophile>
the night is yet young
<alexgordon>
usually it's more like 4:30am
<alexgordon>
prophile: I'm trying to list all the different types of programs
<prophile>
big ones, small ones, some as big as your head
<alexgordon>
impossible
<prophile>
I'm coding Java (:<)
<alexgordon>
:O
<prophile>
and listening to John Bercow giving a lecture
<alexgordon>
:OOO
<alexgordon>
the horror
<alexgordon>
prophile: have you noticed how almost all languages suck for making GUI programs?
<prophile>
smalltalk doesn't
<alexgordon>
only the smalltalk based ones are any good (objc, ruby)
<alexgordon>
you read my mind
<alexgordon>
even python, which is normally a fine language, is shit for GUIs
<prophile>
yup
<alexgordon>
people still do it... but it definitely sucks
<prophile>
yeah, it does
<prophile>
quite a few have nice command line interface libraries :)
<whitequark>
alexgordon: ruby is good for guis?
<whitequark>
tell me more about it
<whitequark>
because I'm still struggling to make a gui in ruby that *just works*, much less convenient to write or something
<alexgordon>
whitequark: oh well it's not, but it would be if someone put some effort into it
<alexgordon>
rubymotion is a proof of concept, at least
<alexgordon>
this comes back to what I was going to say about serializable and unserializable state
<whitequark>
xibs... meh
<alexgordon>
whitequark, prophile: a GUI is inherently global state. For instance, your program needs to hold on to a set number of window references
<prophile>
state monad!
<alexgordon>
OOP is basically a way of managing global state
<prophile>
automaton arrows!
<alexgordon>
...but pretending it's not actually global
<prophile>
or existential state arrows if you're so inclined
<whitequark>
prophile: how about talking in english
<whitequark>
:]
<prophile>
my bachelor's thesis is on FRP semantics
<prophile>
my brain is too full of category theory to talk english
<alexgordon>
haha
<prophile>
when I hiccup, functors come out
<alexgordon>
the object graph that an OOP language creates (or pointers in C) constitute unserializable state. You can't serialize an object graph to a file, then read it back later, because someone's bound to have a file handle in there or something
<prophile>
brb switching graphics cards
<whitequark>
people serialize shit in C in games all the time
<whitequark>
right with pointers
<alexgordon>
whitequark: not the whole program state
<prophile>
actually there has been some work done on user-mode checkpointing in linux
<alexgordon>
usually parts of it, other bits are rebuilt
<prophile>
which *is* serializing the whole program state
prophile has quit [Quit: The Game]
<alexgordon>
e.g. you can't serialize a window handle, you can only serialize the position, title, etc of the window and create a new window the next time your program runs
<alexgordon>
or if you're making a torrent client, you wouldn't ever serialize your whole program state, only a small fraction of it. The rest is recalculated from scratch when the program next starts (by talking to peers)
<prophile>
the low power graphics card makes virtualbox very sad :(
<prophile>
and eclipse sucks
<prophile>
and dies from out of memory conditions if I run it in OS X
<alexgordon>
it does but... notch seems do just fine
<prophile>
but happily runs all day in an ubuntu VM :<
<joelteon>
this guy is just the worst
<alexgordon>
oh that's just java being shit
<prophile>
notch doesn't have to deal with the wretched thing crashing every 5 minutes
<alexgordon>
intellij is the same
<whitequark>
s,java,osx,
<prophile>
and I do mean every 5 minutes
<prophile>
that's not an exaggeration
<prophile>
less if I try to use the refactoring tools
<alexgordon>
intellij rims donkeys on OS X, but it's fine on windows
<whitequark>
see? even windows is better than osx
<prophile>
if it wasn't for the refactoring tools I'd be using vim
<alexgordon>
anyway where was I? oh right, leadership
<prophile>
but oh god they're so useful
<upgrayeddd>
I tried using emacs-eclim bridge to do java on emacs
<upgrayeddd>
but it was painful and i returned to eclipse
<whitequark>
upgrayeddd: who are you?
<upgrayeddd>
whitequark: upgrayeddd
<whitequark>
oh ok
jesusabdullah has joined #elliottcable
<alexgordon>
it's jesus!
<alexgordon>
so basically global state is a necessary part of GUI programs
<alexgordon>
e.g. for an RPG, there's the player's position in the world, their inventory, etc
<whitequark>
I wonder. think of a multiplayer game
<whitequark>
there's no shared global state but an immutable timeline of events
<alexgordon>
even in a multiplayer game, the state is global, but just an array of other players
<whitequark>
think deeper
<alexgordon>
when new information comes in about players' movements, the global state is updated
<whitequark>
you don't want to "modify a field", you want "most recent snapshot"
<alexgordon>
but ultimately what you're doing is modifying a field
<whitequark>
I don't think it is the same as global state in traditional sense
<whitequark>
no, I'm issuing an event
<whitequark>
which will happen some time after, or perhaps not at all if some other event prevents this one
<whitequark>
because sync is not immediate
<whitequark>
e.g. two players in a race to pick a thing.
<alexgordon>
maybe it's a failure of imagination, but I'm not exactly sure how you can make a multiplayer game without global state
<alexgordon>
whitequark: an in-game race or a race condition?
<alexgordon>
not that it makes much of a difference
<whitequark>
both. at time 0, both players issue an event "pick up thing X". then it travels to the server
<whitequark>
the server creates and maintains a total order of all events, which results in some of issued events to fail
<alexgordon>
right
<whitequark>
then it distributes those ordered events which were successful to all clients
<whitequark>
which maintain "global state". in quotes, because it's not directly mutable.
<alexgordon>
oh well depends how you define "mutable"
<whitequark>
this is what I mean by "mmo doesn't have shared mutable state". it has... a non-shared mutable state on a server. which is irrelevant to our GUI discussion!
<alexgordon>
from my view of it, the client has control over its own memory, and it mutates the global state after being directed to by the server
<whitequark>
it's not shared then
* alexgordon
shrugs
<purr>
¯\(º_o)/¯
<whitequark>
and, since it's not directly mutable, is it even relevant? it *observes* some changes in some global state
<alexgordon>
it can't be shared, the speed of light is too slow ;)
<alexgordon>
if by shared you mean consistent
<whitequark>
no, I mean "more than one writer"
<alexgordon>
well the client writes it, because the server tells it to :P
<alexgordon>
but the client state definitely exists
<alexgordon>
we can say that
<whitequark>
it exists.
<whitequark>
and it is global.
<whitequark>
it probably doesn't make sense to describe client in terms of a timeline anyway; most recent state is what's relevant.
<whitequark>
god bless acetaminophen
<alexgordon>
ha
Willox has joined #elliottcable
Willox has quit [Client Quit]
<alexgordon>
this is really a simplified model, netcode is beyond me in modern games
<alexgordon>
various layers of anti-cheat, and RTSs and FPSs need to anticipate what's going to happen, and smoothly interpolate events, etc
<alexgordon>
but you can contrast a game to say a matlab session
<alexgordon>
which is an _entirely_ type of global state
<whitequark>
well... singleplayer game is definitely mutable global state
<prophile>
howso?
<prophile>
as with most of these event-driven things, I imagine it as basically completely pure
<alexgordon>
you can imagine whatever you want ;)
<prophile>
Game = InputEvent -> ([OutputEvent], Game)
<prophile>
there's no need for global state kept around there
<alexgordon>
ok now make crysis using that model
<alexgordon>
you can model simple games like maybe tetris that way
<prophile>
"that's a nice little model but it can't be used in real-world programs?"
<prophile>
that was said about first structured programming then relational databases
<alexgordon>
but I feel like trying to think about Flappy Bird that way would make your brain implode
<prophile>
I unfortunately don't have quite enough spare time to make crysis with it to prove an argument
<whitequark>
prophile: Game is your global state there
<prophile>
whitequark: Game is a function, that's all
<whitequark>
that's irrelevant
<prophile>
well what precisely do you mean by "global state"
<whitequark>
in practice, you just reduce all of your mutable global state to one reference kept to "current Game"
<whitequark>
it's basically hoisting global mutable state to the uppermost level
<prophile>
<prophile> what precisely do you mean by "global state"
<whitequark>
a chunk of data entirely describing the game's behavior to the next arriving event
<whitequark>
I'm looking at it from player's POV
<prophile>
so what you're saying is essentially "games are stateful"
<prophile>
I can't disagree with that
<whitequark>
exactly
<whitequark>
you can model *one step* of a game with a pure function, sure
<alexgordon>
right
<alexgordon>
prophile: but that ain't going to fly anyway in a real world
<whitequark>
this absolutely does not contradict anything I wanted to say about this
<alexgordon>
in a real game you have a render loop
<whitequark>
irrelevant minutae
<alexgordon>
which is the main "tick" of your game
<alexgordon>
some things happen once per render cycle
<whitequark>
alexgordon: data InputEvent = Refresh | ...
<alexgordon>
other things are more flexible (like AI)
<whitequark>
= Refresh | Tick | MouseMove | etc
<prophile>
whitequark: I beg to differ, the model I offered above is all the steps modelled with pure functions
<whitequark>
hrm
<prophile>
what precisely are we arguing here
<whitequark>
I have no idea actually
<alexgordon>
absolutely no clue
<prophile>
I got the impression it was "interactive programs are hard because they have global state" to start with
<whitequark>
yes
<whitequark>
but... they're inherently stateful
<prophile>
so above that was reduced to "interactive programs are hard because they are stateful"
<alexgordon>
prophile: actually, no I was talking about programming language design and how some languages are better for stateful programs and some aren't
<prophile>
^ this sounds like a much more interesting discussion
<prophile>
let's have that one
<alexgordon>
C++ is undeniably good for making games, even though sucks in numerous ways
<whitequark>
though it's not as much due to statefulness
<prophile>
here's something ruby, smalltalk and now obj-c all have in common: they all have blocks
<prophile>
python's sort of half-hearted on that with lambda expressions
<alexgordon>
prophile: objc didn't have blocks until recently though
<whitequark>
but more to control over low-level details, which happen to be relevant today
<prophile>
and the less said about C or Java's bits the better
<prophile>
alexgordon: a fair point
<whitequark>
Java 8 has proper lambdas now
<whitequark>
with inference
<prophile>
they are all also quite dynamic
<prophile>
which might make for easier binding to bits of GUIs
<alexgordon>
prophile: I will say that ObjC having blocks makes it possible to write some programs that weren't feasible before
<prophile>
I'm dying to say something about turing completeness but I know what you mean
<alexgordon>
when you had to mess around with threads and passing state around, it was so _dangerous_ that I'd just pre-emptively say No to a program that required a high degree of concurrency
<prophile>
language and concurrency problems are easy unless you have state
<alexgordon>
yeah turing completeness only concerns the abilities of the computer ;)
<alexgordon>
you know, what python sucks at is the ability to declare state
<alexgordon>
python objects are implicit, you just assign stuff to self anywhere in your methods
<prophile>
you know, FRP is nice... :)
<alexgordon>
*python instance variables
<prophile>
it has explicit state!
<alexgordon>
so object state is really hard to control in python
<alexgordon>
in objc all instance variables are explicit, so it's safer and therefore more ubiquitous
<prophile>
"object state is really hard to control in python" lol
<purr>
lol
<prophile>
I've been working in semantics for too long this week
<prophile>
imperative languages in general now all seem really brittle to me
<prophile>
it's a disease
<alexgordon>
ha but notice it's only if you have state
<whitequark>
I can't write ruby after ocaml anymore
<whitequark>
WHY IS THERE NO TYPES
<whitequark>
ARGH
<alexgordon>
take django for instance, very little state (except for the models/database layer)
<alexgordon>
you take a request, you return a response
<alexgordon>
it goes through various levels of templates and middleends and views and whatever, but django apps are not internally stateful
<alexgordon>
and for that reason, python is a brilliant language for that purpose
<alexgordon>
in fact the most brittle part of django I find are the models -- the stateful bit
<prophile>
now port it to idris <3
<alexgordon>
python is also brilliant for scripting, again no state
<whitequark>
scripting has no state?!
<alexgordon>
whitequark: I mean like shell scripts
<whitequark>
scripting is all about implicit global state, I mean, look at perl
<whitequark>
exactly
<whitequark>
set -e
<whitequark>
env vars
<whitequark>
etc etc
<alexgordon>
not what I mean by state, but I get your point
<prophile>
this isn't part of the argument, but set -e should be beaten into every undergraduate until they're mindlessly babbling it to a team of psychiatrists in a padded ward
<alexgordon>
scripts terminate by themselves, so any "state" is really just a glorified local variable in a glorified function
<prophile>
local variables are state
<alexgordon>
not global state
<prophile>
the difference being?
<alexgordon>
hm well it's obvious but hard to explain :P
<alexgordon>
that usually means I'm wrong
<prophile>
:)
<whitequark>
alexgordon: filesystem
<alexgordon>
imagine a script that reads items from a file, then adds them up and prints the result
<whitequark>
global state.
<alexgordon>
if the file is very big, it may take a long time to add up all those numbers
<alexgordon>
but eventually it will get to the end, print the result and terminate
<alexgordon>
so the accumulator variable is "state" but it's kind of not really relevant
<prophile>
so state is global if it's in a program that isn't known to terminate?
<alexgordon>
exactly
<whitequark>
hm
<whitequark>
interesting definition
<prophile>
then what we're talking about isn't really state, it's termination properties
<alexgordon>
wellllll
<alexgordon>
you might have a program that tries to find a counter example to the riemann hypothesis
<alexgordon>
it will probably run forever (or until it's killed) but it's not really different from the program described above
<prophile>
hm
<prophile>
so I'm thinking the definition may go something like this
<prophile>
(1) you have a program which can be split into a series of steps, each of which is the same shape
<prophile>
(2) if the computation of a step depends on the result of a previous step, that state is global?
<prophile>
although no, that's not right, because the accumulation example would be global state under that definition
<prophile>
hm
<alexgordon>
(1) some programs take an input, perform a (possibly side-effecting) computation, and possibly return at the end. These programs are NOT stateful
<prophile>
so is it to do with interleaving of input and computation?
<whitequark>
I think I get it
<whitequark>
some shell scripts are like pure functions wrt/ their input and output
<alexgordon>
(2) other programs have a run-loop or something equivalent to a run-loop, and interact with their environment, and are either killed by outside forces, or decide to kill themsleves
<whitequark>
so you view the script as a black box with a set of guarantees, kinda
<whitequark>
hence local vars are irrelevant
<whitequark>
alexgordon: is it so?
<alexgordon>
yeah pretty much, modulo some details
<prophile>
whitequark: okay, so it's finding an input and output such that the program is isomorphic to a function input -> output?
<whitequark>
finding an input and output?
<whitequark>
no
<alexgordon>
whitequark: you might have a script that reads from a file and writes out to a file every so often
<prophile>
sorry, finding an input and output type
<whitequark>
hm
<alexgordon>
so it doesn't just output at the end, it outputs throughout the process
<prophile>
"code on stdin" or "code on stdin + contents of <such and such file>" for instance
<prophile>
alexgordon: what's the difference?
<alexgordon>
there's definitely a gray area between some scripts and some daemons
<alexgordon>
I don't think there's a hard and fast line
<prophile>
I'm a bit wary of "grey areas" if it can be boiled down to formal semantics
<prophile>
they make me sad
<prophile>
and yet somehow
<alexgordon>
ah the academic's curse
<prophile>
aroused
<prophile>
:£
<whitequark>
lol
<purr>
lol
<whitequark>
sad horny prophile
* prophile
bones a tub of ice cream
<alexgordon>
ok how about this
<prophile>
we'll kill all the humans
<alexgordon>
stateful programs are ones that are autonomous
<prophile>
that's a great idea
<prophile>
what does autonomous mean?
<alexgordon>
acting of its own free will
<whitequark>
wat
<alexgordon>
as far as a computer can act of its own free will
<prophile>
wat
<alexgordon>
xD
<alexgordon>
a GUI program is autonomous right, you don't manage it, you interact with it
<alexgordon>
you say to the GUI program "why I would love to click your button"
<prophile>
"mr gordon, my GUI program is a bit tangled, how do I refactor this?"
<alexgordon>
similarly with a daemon, you set it off free into the world, and it does its thing
<prophile>
"well, first you need to learn about the philosophies of Democritus"
<alexgordon>
e.g. a buildbot may check to see if your git has been updated and automatically rebuild your project
<prophile>
how is that not true of a shell script
<prophile>
you set it off into the free world and it does its thing (counting up numbers in a file)
<alexgordon>
hm well I don't see it that way
<alexgordon>
you start it off, it does its thing yes, but it's running inside your terminal window as it does it, and you can kill it at any time with a keystroke if you don't like what it's doing
<alexgordon>
shell scripts are inherently supervised, unless you go off to put the kettle on
<prophile>
so a daemon is stateful unless you start it in foreground mode
<alexgordon>
like I said there's vagueness in there, some daemons can be a lot like shell scripts and vice versa
<alexgordon>
but the two categories seem more different than they are alike
vil_ is now known as vil
<alexgordon>
a daemon has to have the tools to survive on its own, since there's rarely anybody paying attention to it
<prophile>
what about games? they are stateful but keep the user's full attention
<alexgordon>
e.g. for that buildbot, a shell script version of it would do the check when it starts, and then compile the thing, otherwise it would terminate
<prophile>
then we're coming back to the termination properties
* whitequark
is proud of himself
<whitequark>
I just fixed my bed frame
<whitequark>
with a drill and some swearing
<alexgordon>
a daemon version would have continually check the repo status (using some mechanism), and start off the build process when it noticed a change
<prophile>
so it's whether it's event-driven?
<alexgordon>
mmm no because a django app is event-driven but not really stateful
<prophile>
what makes the django app different from the buildbot?
<prophile>
the django app gets a request then vends a response
<prophile>
the buildbot gets a commit then vends a build
<alexgordon>
true
<alexgordon>
if you want to get all technical, the django app uses something like uwsgi to receive the request and send the response
<alexgordon>
but even that isn't really stateful
<alexgordon>
prophile: I think the root of the problem is it's 4am and I've totally lost the mental capacity to reason
<glowcoil>
prophile: what's your view on computation time in frp
<glowcoil>
prophile: like, delays/latency
<glowcoil>
prophile: and continuous time and all that
<prophile>
glowcoil: computation time?
<prophile>
my gut instinct on continuous time is that it's an exercise in futility, although some very smart people disagree
<prophile>
and that computation should be triggered only by a change in the FRP networks' inputs, and if you have global time it should be the time that the change in input occurred
<glowcoil>
prophile: ok cool
<glowcoil>
prophile: because for a while i really wanted to have like continuous time but finally realized it's a very leaky abstraction
<glowcoil>
prophile: so i like that
<prophile>
conal elliott argues very strongly for continuous time in FRP
<prophile>
and having invented it he's somewhat of an authority on it
<glowcoil>
haha yeah
<glowcoil>
i was a disciple for a while
<prophile>
he's also a generally cool guy who hangs around in #haskell answering questions
<prophile>
I've been basically swayed by netwire's general approach though
<prophile>
your definition of shell scripts includes clang
<alexgordon>
prophile: :D
<alexgordon>
am I wrong?
<prophile>
well, yes
<prophile>
it's written in C++
<prophile>
a shell script is a script
<prophile>
for a shell
<prophile>
matlab does need to be fast
<alexgordon>
it doesn't do a good job of it
<prophile>
depends on what you're trying to do
<prophile>
matlab's matrix multiplication, say, or FFT are very fast indeed
<alexgordon>
ok replace shell script with CLI tool
<prophile>
k
<prophile>
"Slow" under "Supervised" for libraries?
prophile has quit [Quit: The Game]
<alexgordon>
fixed
<alexgordon>
glowcoil: yo so
<alexgordon>
what is it about smalltalk that's so good at GUIs
<alexgordon>
and java, which is related, not so good
* alexgordon
compares and contrasts java and smalltalk/objc/ruby
<alexgordon>
for one, smalltalk does not do much inheritance
<alexgordon>
and smalltalk puts a big emphasis on messaging
<alexgordon>
and "everything is an object"
<alexgordon>
no interfaces in smalltalk
<alexgordon>
but categories are important in objc and ruby
<alexgordon>
oh instance variables naturally
<alexgordon>
ruby has class variables which nobody uses
<alexgordon>
properties
<alexgordon>
initialization...
eligrey has joined #elliottcable
eligrey has quit [Remote host closed the connection]
eligrey has joined #elliottcable
<glowcoil>
alexgordon: i haven't ever actually written a gui and enjoyed it
<glowcoil>
alexgordon: the automatic mvc of css+html+js is *okay*, if you can power through the grossness
<glowcoil>
alexgordon: and shoes was pretty cute in ruby
<glowcoil>
haven't used smalltalk
<glowcoil>
sounds fun
<alexgordon>
glowcoil: css/html/js sucks
<alexgordon>
glowcoil: I enjoy writing GUIs in objc/cocoa
<alexgordon>
and I would probably enjoy it in ruby
<alexgordon>
glowcoil: I feel like actors and OOP really go well together
<alexgordon>
glowcoil: what do you think of rust's idea of putting tasks in a tree?
<alexgordon>
I guess it's unix's idea :P
<alexgordon>
glowcoil: so an object can be referenced in a local variable, but it can only have one _owner_ in the object tree
<alexgordon>
I feel like that would force people to structure their program better
<alexgordon>
although it would sacrifice a lot of flexibility
Determinist has joined #elliottcable
<glowcoil>
alexgordon: that's practically paws
<alexgordon>
it is?
<glowcoil>
the whole owners+concurrency thing
<alexgordon>
maybe
prophile has joined #elliottcable
<alexgordon>
prophile: we're (ok I am) designing a perfect OOP language
<glowcoil>
lol
<purr>
lol
<alexgordon>
OOP is pretty fucking complicated
<glowcoil>
alexgordon: i want something less OOP and something more, ideal abstract data types
<alexgordon>
glowcoil: the whole point about OOP is encapsulated state
<alexgordon>
this is where everybody goes wrong
<alexgordon>
classes are not data types
<alexgordon>
they are merely specifications for objects
<alexgordon>
and objects are merely little bits of state
<glowcoil>
well i mean i see what you're getting at
<glowcoil>
oop is like
<prophile>
I'm learning the alto sax
<glowcoil>
name a semantic section of your program
<glowcoil>
describe ways it can interact with other sections
<glowcoil>
and that's different from data types
<prophile>
picked one up for the first time 5m ago
<alexgordon>
prophile: yay
<alexgordon>
prophile: did everybody run away?
<glowcoil>
prophile: neat, saxes are great
<alexgordon>
glowcoil: right you've got it exactly
<alexgordon>
objects are partitions of the state of your program
<alexgordon>
it's like your program state is a big cake, and you're cutting it up into little pieces so it's more manageable
<alexgordon>
mmm cake
<alexgordon>
data has got to exist somewhere. In functional languages it exists in function arguments, let bindings and closures. In OOP languages it exists in instance variables
<glowcoil>
right
<glowcoil>
though oop kind of has a turtles-all-the-way-down approach to data
<alexgordon>
yeah I don't like that
<glowcoil>
oh hm
<glowcoil>
yeah on second thought i'm not sure if i do either
<alexgordon>
though in java and objc at least you have primitive types
<glowcoil>
it's kind of missing the point of oop
<alexgordon>
like int
<glowcoil>
like, erlang tasks and haskell modules seem to be similar
<glowcoil>
yknow
<glowcoil>
like, hiding shit
<glowcoil>
erlang tasks much more so
<glowcoil>
but like
<glowcoil>
yeah
<glowcoil>
but at the same time there's a benefit to turtles all the way down because otherwise there's a point at which you switch abstractions
<glowcoil>
which is never fun
<glowcoil>
should this be a function, or a task?
<alexgordon>
the key is to make the abstractions different enough
<alexgordon>
if there's too much overlap, hand wringing occurs
<glowcoil>
yeahi guess
<alexgordon>
glowcoil: yeah so my idea (which is apparently paws'?) is to turn objects into processes
<glowcoil>
alexgordon: that's not so much what paws is
<glowcoil>
alexgordon: what i was saying paws is like is the whole
<glowcoil>
alexgordon: ownership thing
<alexgordon>
ah ok
<alexgordon>
if you think about it, objects and processes are exactly the same
<alexgordon>
encapsulations of state
<glowcoil>
though that *is* what the unnamed thing in my head that has recently become "hands" is
<alexgordon>
they can come into existence, and be destroyed
<alexgordon>
you can have communication between processes
<glowcoil>
and now that you've explicitly mentioned it I can work towards it more lucidly
<alexgordon>
haha
<alexgordon>
ME FIRST
<glowcoil>
like, here was my vision
<glowcoil>
so you have
<glowcoil>
a game object
<glowcoil>
like
<glowcoil>
mario
<glowcoil>
with all his properties defined by mutual recursion inside him
<glowcoil>
and then some of them are public and some are private
<alexgordon>
prophile: listening to brecker in your honour
<glowcoil>
so you choose what to expose
<alexgordon>
lol inside mario
<purr>
lol
<glowcoil>
so like some intermediate stuff, like calculations, are private
<glowcoil>
so you have like
<glowcoil>
let mario = { x = 3, y = 4 } where { asdf, asdf }
<glowcoil>
right?
<glowcoil>
but you have stuff about creation and destruction too
<alexgordon>
errrr ok
<alexgordon>
that's an odd syntax
<alexgordon>
guess it makes sense
<alexgordon>
glowcoil: so like a multi-closure?
<glowcoil>
hm i guess yeah
<glowcoil>
yeah
<alexgordon>
closure is one function + many captured variables
<glowcoil>
yeah, many exposed variables + many captured variablaes
<alexgordon>
(like a class with one function (that's exactly how they work in java))
<glowcoil>
which are effectively the private variables
<glowcoil>
yeah
<alexgordon>
I really like that idea
<alexgordon>
I've never seen anything like that in a language, perhaps for good reason
<glowcoil>
yeah it makes the most sense with reactive/frp type of stuff
<glowcoil>
it seem
<glowcoil>
s
<glowcoil>
and it seems much more in line with alan kay's original notion of oop as being all about messaging
<glowcoil>
and it seems a *lot* like erlang's processes
<alexgordon>
glowcoil: I was playing around before with this idea of "reincarnation"
<alexgordon>
usually the life cycle of objects is: 1) construction, 2) usage, 3) destruction
<alexgordon>
but what if you had an object that, instead of dying, could reincarnate itself if it got into an error condition
<alexgordon>
this is more useful for process-like objects
<alexgordon>
like a daemon that restarts itself if it crashes
<glowcoil>
sounds like insanities
<glowcoil>
and also erlang
<alexgordon>
:D
<glowcoil>
keep in mind
<glowcoil>
i only know about erlang from evangelical blog posts and tweets
<glowcoil>
never used it
* alexgordon
approaches ELLIOTTCABLE in the limit
<ELLIOTTCABLE>
What
<alexgordon>
ELLIOTTCABLE: we're having words. about programming
<ELLIOTTCABLE>
Meh
<alexgordon>
:D
<ELLIOTTCABLE>
Bbl desk
<glowcoil>
lol
<purr>
lol
<alexgordon>
glowcoil: seems most people, like me, really really like the idea of erlang
<alexgordon>
but it's a disgusting language
<ELLIOTTCABLE>
Why do rugs coil so terribly
<ELLIOTTCABLE>
Dislike dislike dislike
<glowcoil>
alexgordon: oh absolutely
<alexgordon>
glowcoil: so unix + smalltalk, what could go wrong
<glowcoil>
haha
<glowcoil>
well i like one of those two things
<alexgordon>
cheese and watermelon
<alexgordon>
glowcoil: hm so if each process has a set number of children that makes distributed objects really easy
<alexgordon>
(erm, by set number of children, I mean that each child has exactly one parent)
<alexgordon>
since the biggest problem with distributed objects is garbage collection
<alexgordon>
one thing I love and hate about ObjC is KVC/KVO
<alexgordon>
it's a great idea, although with a bad interface
<glowcoil>
kvc?
<glowcoil>
is that the reactive binding thing
<alexgordon>
glowcoil: errr maybe?
<glowcoil>
what is it
<alexgordon>
glowcoil: you know @property in ObjC?
<alexgordon>
when you do @property int x;
<alexgordon>
you can subscribe to changes of "x"
<alexgordon>
so if I do self.x = 10; anybody "observers" of the value of x will get a callback
<alexgordon>
*any "observers"
<alexgordon>
that's KVO. KVC means that you can set things using strings in a dynamic way. I guess it probably works for ints
<alexgordon>
[foo valueForKey:@"x"] would return @10
<alexgordon>
if you have multiple levels of objects you can use a "key path"
<alexgordon>
[foo valueForKeyPath:@"bar.foo.x"]
<alexgordon>
there's also accumulators and stuff like @sum
<glowcoil>
oh ok
<alexgordon>
it's cool stuff, very dynamic, very not Java
<alexgordon>
glowcoil: the most notable user of all of this is "bindings" in interface builder where you can get UI elements "reacting" to changes in the model, or to other UI elements
* alexgordon
likes putting quotes "around" things
<glowcoil>
yeah ok it's what i thought
<glowcoil>
objc always has this reading barrier between me and doing things though
<glowcoil>
so i never tried it out
<alexgordon>
yah
<alexgordon>
glowcoil: also the whole mac only thing
<alexgordon>
if objc worked on other platforms I bet someone would have built a cross platform framework for it
<glowcoil>
i think there's some stuff
<glowcoil>
and cross platform frameworks
<glowcoil>
that literally no one uses
<alexgordon>
LOL yeah
<purr>
LOL
<glowcoil>
man objc seems nice there's just so many patterns to read about
<alexgordon>
smalltalk man!
<alexgordon>
alan kay wasn't crazy
<glowcoil>
ya
<glowcoil>
maannnn i just have to make hands
<glowcoil>
should i compile to llvm or javascript first
<alexgordon>
glowcoil: javascript! lol whitequark was asking the same question about JVM
<purr>
lol
<glowcoil>
ok javascript it is
<glowcoil>
i spose
<glowcoil>
:p
<alexgordon>
js sucks
<alexgordon>
but it's great for prototyping
<alexgordon>
make sure you can handle the little sister before you try the big daddy
<glowcoil>
yeah :p
<glowcoil>
it also is like
<glowcoil>
very leaky
<glowcoil>
like
<glowcoil>
if you do things wrong it doesn't fail satisfyingly, you just get weird holes
<glowcoil>
so it's not very satisfying to compile to
Sgeo has joined #elliottcable
<alexgordon>
glowcoil: so my probjcects are going to be 100% async
<alexgordon>
one too many letters in there
<alexgordon>
but anyway, methods don't return, they take a continuation
<glowcoil>
cool
<alexgordon>
and veeeeery dynamic
<alexgordon>
fuck all this static shit as far as objects go :P
<glowcoil>
push-args-and-jump is a different instruction from like, suspend state on stack
<glowcoil>
so tco falls out of the arch
<alexgordon>
glowcoil: this object oriented thing I'm building. I'll probably design something really crazy, then cut it back to make it suitable for furrow eventually
<alexgordon>
long term project I'm sure
<glowcoil>
ok cool
<glowcoil>
so i want to have this really good set of like
<glowcoil>
comprehension control structures
<glowcoil>
for hands
<alexgordon>
e.g.?
<glowcoil>
i mean generator comprehensions and Rx extensions are good examples