Willox has quit [Read error: Connection reset by peer]
PLejeck has quit [Read error: Connection reset by peer]
PLejeck has joined #elliottcable
sharkbot has quit [Remote host closed the connection]
sharkbot has joined #elliottcable
<glowcoil>
whitequark: that's not even relevant
<glowcoil>
whitequark: if you're making as radical changes to your programming environment as i am envisioning then you are probably not interfacing this with all your old code
<whitequark>
then we're back to the "toy language" problem
<whitequark>
meaning:
<whitequark>
1) real-world software *always* has to interact with legacy code, but even barring that
<whitequark>
2) legacy code is written the way it is, for a good reason
<whitequark>
in this particular case, because the process is more easily represented as stateful, or, equivalently important, the process is built around interaction with external stateful service
<whitequark>
so are you saying to throw out, say, all existing databases in favor of some insane pure crap?
<whitequark>
it's not even possible in general case
<whitequark>
try, say, using less haskell and reading more real-world, shitty, valuable code. especially written by someone whose main occupation is not a programmer.
<whitequark>
since those are the people most likely to benefit from the changes... professional programmers don't have that much problems with cli and abstractions anyway
<whitequark>
(and have more problems relearning to a completely different technique)
<devyn>
.NET programmers usually avoid the CLI
<devyn>
so I wouldn't say that
<devyn>
I've seen people build ridiculous GUIs to do things they could have made CLIs for in two seconds for no good reason
<devyn>
other than that they don't like it
<whitequark>
okay, scratch the cli part
<whitequark>
it's really about abstraction anyway in this case
<glowcoil>
whitequark: jesus christ you are such a pessimist
<glowcoil>
whitequark: i haven't written a fucking line of anything but java or javascript in months and months
<glowcoil>
whitequark: certainly no haskell
<whitequark>
that wasn't meant to be read literally. anyway, the bottom line is, what you (or it seems to me: more bret victor so far; perhaps I misunderstand) propose does work but a set of rather narrow cases which are a sweet spot for this technique
<whitequark>
and it doesn't work at all for code which does not hit said sweet spot
<glowcoil>
remember how many times i said embrace plurality and don't try to use one representation
<glowcoil>
i disagree with bret victor, i think he rejects what's there without providing what he imagines as a platonic ideal
<whitequark>
sure, but this technique does not exactly combine easily with others
<whitequark>
for example it requires you to have a) pure algorithm b) impure harness around it to display results c) with a clear distinction between both where you can hook your environment
<whitequark>
and if you want to apply it more than once, you have to pull more and more code in the pure part
<whitequark>
well, combine other pure parts to make bigger ones. anyhow, see why I said 'haskell' ?
<glowcoil>
everything you just said is wrong
<whitequark>
please do explain
<glowcoil>
first of all you can show a visualization of before and after states with a side-effecting function
<glowcoil>
also you can have side-effecting functions you test with arguments and if they depend on state then it is a bad tool for visualizing thjem
<whitequark>
(before and after) sure. now you pull the slider and... what happens?
<whitequark>
(bad tool) sure. what are the other tools?
<glowcoil>
depends on what the underlying language is
<whitequark>
well, aren't you designing one?
<devyn>
22:00:33 <+glowcoil> everything you just said is wrong
<devyn>
wow, fiesty
<whitequark>
fiesty: "everything you did in your life was in vain"
<glowcoil>
devyn: whitequark is being a huge fucking pessimist and refuses to believe that there's any possible way something i say can be viable
<devyn>
feisty.
<devyn>
oops
<whitequark>
I'm not refusing to believe, I do not understand
<whitequark>
big difference
gq has quit []
<whitequark>
I *want* to believe, lol.
<purr>
lol
<devyn>
glowcoil: I don't think that's true; he just doesn't see how something revolutionary can ever succeed when we've already got so much infrastructure
<whitequark>
that's partly true, but only partly
<glowcoil>
whitequark: saying "try using less haskell and using more real world code" is not really "wanting to believe", it's being very condescending
<whitequark>
I think a tool which rejects existing infrastructure *completely* is bound to fail no matter what
<devyn>
he's just asking you to approach this from less of a mathematical ideal perspective
<whitequark>
glowcoil: remember that I also really want this to be true and have my own similar ideas (Livescript)
<whitequark>
so, yeah, I do want it
<devyn>
essentially: how can you do this in an evolutionary way
<devyn>
without changing everything
<whitequark>
I just can't see how it looks in the big picture so far, inside a complete development environment
<whitequark>
and a huge part of it is thinking of real code. Say this PID controller I have laying here, it's in a way a problem yielding rather well to such analytical approach
<glowcoil>
i don't have a full complete picture, i'm not working on this project
<whitequark>
yet if you crack it open and look inside, d'aww, *none* of that code is pure
<glowcoil>
these are idle ideas
<glowcoil>
the things i'm trying to make right now are music and games, when i don't have shit tons of homework to do
<glowcoil>
everyone has so fucking little imagination about what "pure" means
<glowcoil>
it's not like
<glowcoil>
you either have
<glowcoil>
a bunch of fucking functions that take and return adts, or a bucnh of fucking statements and pointers and globals and c
<whitequark>
I don't think like that
<glowcoil>
there are so many fucking possibilities
<whitequark>
sure you can encapsulate state at various levels, but that requires you to write more and more support code for the DE
<whitequark>
perhaps s,write,generate,; bottom line: understand it
<whitequark>
hm, well. maybe if language was built around stateful processes with well-defined creation and interaction interfaces
<whitequark>
that could work
<whitequark>
so that all code you write naturally encapsulates state well
<whitequark>
I don't think I've seen anything quite like that. only vaguely similar stuff
<whitequark>
that... that actually may become a thing
<yorickpeterse>
AWWWW SHEEEEE, a libre arte package
<yorickpeterse>
what?
<yorickpeterse>
Node on hardware?
<yorickpeterse>
it already is
<yorick>
yorickpeterse: it's the music store on the gijsbrecht isn't it
<yorick>
I hate that music store
<yorickpeterse>
yup
<yorickpeterse>
haha
<yorickpeterse>
how so?
<yorick>
they sold me a showroom model with the promise a new one would be arriving soon to replace it, and it took them months
<yorick>
like "hmm, you can have that one, but we don't have that yet so you can loan this one for now" and then it took them months to order the actual thing I bought
<yorickpeterse>
so this fucking art pack comes with a fucking Slackware ebook
<yorickpeterse>
how the hell is that even related
<yorick>
because someone googled linux+art?
<yorickpeterse>
"dethmetal.sf2" not sure if typo...
<yorick>
and then scrolled through pages to see the word slackware