00:02:09 -!- ais523 has quit (Remote closed the connection).
00:35:59 <ehird> GregorR: It worked, actually
00:36:29 <ehird> I moved the whole system to a subdirectory and migrated debian outwards
00:36:49 <ehird> and everything worked instantly, but now it won't boot due to a seemingly unsolvable without a lot more work problem
00:36:54 <ehird> I'll need to get at the HD to rest it
00:39:23 <ehird> GregorR: but who says you can't totally move a linux system while it runs?
00:40:04 <GregorR> If you move /lib, you will no longer be able to run new dynamically linked programs.
00:40:35 <GregorR> (By new I mean you won't be able to load new ones, not that you won't be able to load ones you haven't loaded before or something)
00:41:10 <GregorR> Because dynamically-linked programs depend on the existence and location of /lib/ld-linux.so.foo
00:41:42 <GregorR> So if mv still worked, it was probably statically linked (busybox?)
00:52:09 -!- puzzlet_ has quit (Remote closed the connection).
00:52:12 -!- puzzlet has joined.
00:54:17 -!- coppro has joined.
00:56:59 <ehird> GregorR: Busybox, yeah.
00:57:13 <ehird> GregorR: Also, as soon as I moved debian in, that file existed, of course.
01:00:20 -!- Asztal has quit (Read error: 110 (Connection timed out)).
01:04:12 <ehird> GregorR: So I migrated it pretty much perfectly modulo bootup.
01:04:25 <ehird> (It is initramfs, btw.)
01:04:34 <ehird> (It uses squashfs as well as /linuxrc)
01:09:06 -!- coppro has quit (Remote closed the connection).
01:09:37 <GregorR> Yeah, but you still need to run 'mv' to move debian in, and was mv not statically linked, you'd be all "oh shiiiiiiiiiiiiiiiiiiiiiiiiii"
01:12:01 -!- coppro has joined.
01:14:13 <ehird> GregorR: Hooray for busybox
01:32:57 <ehird> Future civilisations will develop whole theories of psychology as to why we have bugs in all our systems due to an oversight that could only be a cognitive defect: a few keypresses giving full access.
01:33:03 <ehird> They come up with nothing, and never explain the mystery of:
01:33:09 <ehird> ↑ ↑ ↓ ↓ ← → ← → B A
01:36:46 -!- puzzlet has quit (Remote closed the connection).
01:45:06 -!- puzzlet has joined.
01:55:07 -!- puzzlet has quit (Remote closed the connection).
01:55:11 -!- puzzlet has joined.
02:13:45 -!- Pthing has quit (Remote closed the connection).
03:24:06 * GregorR is trying to make peppermint soda.
03:42:31 -!- ehird has quit.
04:08:18 -!- ehird has joined.
04:17:57 <ehird> "Sometimes you may want to do the opposite of abs(): turn a positive number into a negative."
04:17:57 <ehird> http://us.php.net/manual/en/function.abs.php#58508
04:27:20 <ehird> GregorR: Go one comment ↑ up
04:27:28 <ehird> You will jump off a bridge
04:28:06 <ehird> With great difficulty!
04:28:44 <ehird> GregorR: Also, just keep scrolling up.
04:28:47 <ehird> They argue about it.
04:29:21 <GregorR> I scrolled up one more to see the not-retarded response (although I'd just use -abs($x), there's no reason to put that in a function)
04:29:29 <ehird> Just as a note to the post below, you could join that function into one line instead of two as follows:
04:29:30 <ehird> function change_pol($integer){
04:29:30 <ehird> return ((!is_numeric($integer)?false:(0 - $integer));
04:29:36 <ehird> GregorR: It continues right up to the top
04:30:50 * GregorR stabs himself in the face.
04:31:12 -!- coppro has quit (Read error: 104 (Connection reset by peer)).
04:37:09 -!- coppro has joined.
04:40:46 -!- coppro has quit (Remote closed the connection).
04:41:06 <ehird> huh, the original unix ran on a machine with less than 64k of memory
04:41:09 <ehird> of course that's obvious in retrospect
04:42:14 -!- coppro has joined.
05:03:27 <ehird> GregorR: make some swig ingest drink
05:13:29 <GregorR> I couldn't find all the ingredients.
05:15:12 <ehird> GregorR: like, the list, or literally?
05:15:27 <GregorR> Uhh, I have a log, I can find the list :P
05:15:34 <ehird> The only ones that are even slightly non-trivial are lavender and caffeine... and maybe brown sugar if you live in crazytown.
05:15:49 <ehird> (But, you know, brown sugar was ON THE CARDS. It was not mandatory. :P)
05:16:05 <ehird> Want me to ship you some?
05:16:14 <GregorR> Uhhh ... only if I don't have to pay for it :P
05:16:35 <ehird> GregorR: I'm sure the costs of shipping a tiny, tiny bottle overseas are exorbitant :P
05:16:38 <ehird> of course, I could just make it myself.
05:48:29 <ehird> Wow, doing a bidirectional process pipe in C is ... awkward.
05:49:24 <ehird> Like, ridiculously so.
05:53:07 <ehird> Who the fuck designed this shit?
05:57:00 <pikhq> ... Awkward in Unix? Definitely not original. The original design was at least *consistent*. ;)
05:57:26 <pikhq> (that is to say, if it's K&R, I shall murder someone. I'm not sure who.)
05:57:55 <ehird> It's just... holy fuck, you need to do a bunch of pipe calls with 2-element arrays and dup2 and aaaaaaaaaaaaaaaaaaaaaaaaaaa
05:58:06 <ehird> Why can't you just do "rw" on popen and get two files x_x
05:59:02 * ehird writes scandalous_popen
06:01:32 <ehird> I need to use a temporary file on one end anyway.
06:02:49 <ehird> ...mktemp() modifies its argument.
06:02:55 <ehird> it is hard to express how much I hate C
06:05:30 <ehird> I'll try and express how much I hate every C function operating on strings and the environment.
06:07:01 <pikhq> Yeah, the string functions are *really* bad.
06:07:59 <mycroftiv> ironically, when i learned C i was impressed with the string handling, because my expectations were set by Apple ][ BASIC
06:08:08 <mycroftiv> the secret to happiness in life: low expectations
06:08:55 <ehird> The string and environment functions in C are a festering pile of teeming little bugs, except the bugs are actually made of excrement, and you discover that so's the floor; and it's all over your face, except now you're eating it, and vomiting on it, and eating that, and soon you're shitting out bugs
06:08:55 <ehird> and more faeces and contributing to the general mess; meanwhile, the bugs, including the ones of your own creation, painfully detach every single limb in your body, keeping nervous signals connected wirelessly so you still feel the pain. They bore into your brain, where they give you the simultaneous
06:08:55 <ehird> feeling of the worst possible horror and the worst possible pain, but keep you alive for longer than it takes for A(g64,g64) suns to die out just so you can keep experiencing it. At the end, you are buried alive in the pile of shitvomitbugs, and suffocate to death while inhaling in the putrid
06:08:57 <ehird> vapours and indeed the shit, vomit and bugs themselves, along with the rotted remains of your limbs. You expire with this feeling.
06:09:11 <ehird> That is what they are.
06:09:49 <ehird> You are most welcome.
06:11:03 <ehird> Now I have to go and work out the length of some character buffers to allocate, to avoid my computer spending a nanosecond on it at runtime.
06:11:12 <ehird> See you in a few years.
06:12:11 <ehird> Okay, jesus christ; is there a popen that takes an array of arguments instead?
06:12:23 <ehird> I would very much like that.
06:13:10 <mycroftiv> i do plan 9 C which handles it all a bit differently, so im useless for old-fashioned unix standard library stuff
06:13:43 <ehird> Plan 9's string support is marginally more bearable.
06:13:53 <mycroftiv> eh, its still the same stuff really
06:14:09 <ehird> Something like Python's is the goddamn panacea because it just damn works.
06:14:18 <ehird> In fact, I am going to write it, right now.
06:14:33 <ehird> It'll in fact be easier than figuring this out.
06:15:34 <mycroftiv> yeah the thing about C string handling is that you are really supposed to write your own personal C string libraries of stuff and then take them with you for the rest of your life
06:16:34 <ehird> I'm a crazy computer socialist, I want most things to be in the hardware and the rest to be in the closely-related language/OS.
06:17:07 <ehird> (Basically I just don't like stopping my own head from hitting a brick wall as opposed to stopping everyone's, which I guess applies to real-life socialism too.)
06:17:20 <mycroftiv> i like your vision but i dont have the same dislike of building layers of abstraction out of disparate components
06:17:36 <mycroftiv> to me layered abstractions mean that it doesnt matter what the hardware is or does as long as you can get a UTM out of it
06:17:42 <ehird> I like abstraction, I dislike unneeded disbtraction
06:18:11 <mycroftiv> i agree that in practice the 'layers' often fall apart, which is where the problems happen imo
06:18:13 <ehird> take current hardware architectures, they have a huge disparity from our high level languages, the concepts they use (garbage collection, tagged pointers, ...) - yet it's our fault
06:18:40 <ehird> it's perfectly possible to abolish that layer of "abstraction", and the result is a more coherent, faster, less roundabout system
06:18:43 <ehird> and I think that's always a good thing
06:18:50 <pikhq> Because Intel makes great C machines.
06:18:56 <pikhq> (they can throw money at it!)
06:19:04 <ehird> pikhq: do they, though? modern x86 differs quite a lot from C
06:19:09 <pikhq> ... Actually, x86 is not *that* much of a C machine.
06:19:10 <ehird> I think they make great windows machines.
06:19:30 <ehird> In fact their design philosophy is basically that of windows; pile shit on top if it saves us time and money to design.
06:19:36 <pikhq> It's more of an assembly machine -- it was originally designed assuming assembly programs.
06:19:42 <pikhq> ... With a lot of shit added on.
06:19:48 <ehird> (ok, no offence to the intel guys, they're great; it's the climate that forces this)
06:20:14 <mycroftiv> i still dont understand how the chip architecture matters, once you have written an implementation of a given language - thats where my brain fails to make the connection
06:20:24 <ehird> mycroftiv: Sure, you can ignore it, *but*
06:20:30 <mycroftiv> how is fortran on powerpc different from fortran on x86?
06:20:36 <ehird> Ah, that's not the thing though.
06:20:45 <ehird> All "general purpose" architectures aren't really and pretty much suck.
06:20:47 <pikhq> mycroftiv: The architecture limits efficient compilation techniques, for one.
06:20:55 <ehird> I'm talking Lisp on an x86 vs Lisp on a good lisp machine.
06:21:08 <ehird> The latter does checking of tagged pointers in hardware and automatically upgrades to bignums.
06:21:13 <mycroftiv> pikhq: hmm, how is that important? stuff is so fast nowadays compiling is always trivial, isnt it?
06:21:15 <ehird> It handles concurrent, generational garbage collection - in hardware.
06:21:23 <pikhq> To compile most languages to x86, you pretty much compile it to something vaguely like C and then compile C.
06:21:31 <ehird> mycroftiv: The problem is that "good enough" only seems alright because we haven't seen better.
06:21:44 <ehird> We're blinded to what hardware designed for the top-level could do for us.
06:22:04 <mycroftiv> i just dont hear any specifics, and i think that its not theoretically compatible with the reality that everything is a utm
06:22:10 <ehird> Massive, MASSIVE speed increases; Cheaper chips due to a less convoluted design;
06:22:21 <ehird> Energy and therefore money saved by running less cycles - running instead *better* cycles
06:22:30 <ehird> mycroftiv: Yes, everything is *theoretically equivalent in what it can do*.
06:22:32 <ehird> It's about HOW you do it.
06:22:36 <pikhq> mycroftiv: Just because everything in practical use is a UTM doesn't mean that we should be using Brainfuck machine.
06:22:45 <pikhq> using *a* Brainfuck machine, rather.
06:22:52 <mycroftiv> where is a source that demonstrates massive efficiency gains of the type you are talking about?
06:22:53 <ehird> I don't think it's a "real-world" kind of thing either
06:22:58 <ehird> I think it's a correct type of abstraction
06:23:03 <ehird> mycroftiv: nowhere because nobody does this kind of shit
06:23:09 <ehird> I arrive at it through pure reason
06:23:17 <mycroftiv> so why am i supposed to believe your claims, without evidence?
06:23:20 <pikhq> mycroftiv: None, because the last Lisp machine was designed before I was born.
06:23:27 <ehird> mycroftiv: Here is some pure logic to attempt to justify it:
06:23:44 <ehird> If we do 50 x86 instructions to shuffle memory and registers, making conditional branches, ... — just to add two bignums together.
06:23:45 <pikhq> ehird: Hmm. Actually, there has been some of "this kind of shit".
06:24:01 <mycroftiv> as i said, to me logic seems to lie in the direction of 'you make a UTM, then you build abstractions on top, the low level doesnt matter'
06:24:02 <ehird> We do ONE lisp machine instruction, which concurrently does a fixnum addition and checks the tag on the value,
06:24:05 <ehird> sees that it's a bignum
06:24:07 <ehird> discards that result
06:24:11 <pikhq> The JVM was designed to be implementable in hardware, and Sun has actually made Java machines that run Java rather efficiently.
06:24:12 <ehird> and goes into a MICROCODE tight loop
06:24:19 <ehird> that's (a) much faster
06:24:24 <ehird> (b) much, much less pointless shuffling
06:24:31 <ehird> and those are what lead to less power consumption
06:26:15 <mycroftiv> thats a good rationale, but somehow i never got the sense your motivation was really ecological
06:26:42 <ehird> if we use less power
06:26:50 <ehird> we can afford more power of the computational kind
06:26:56 <ehird> at the same $ cost
06:27:00 <ehird> it's a combination of a BETTER result (faster, less power, etc)
06:27:09 <ehird> omitting needless "abstractions" that aren't
06:27:10 <mycroftiv> i guess to me the big issue is that we have spare computational power already that we need to find something useful to do with
06:27:14 <ehird> they're anti-abstractions; they confuse nd obscure the high-level
06:27:17 <ehird> instead of harmonising with it
06:27:26 <ehird> and if we can destroy such silly things, whyever would we not?
06:27:39 <ehird> of course my OS won't run on such chips by default
06:27:45 <ehird> but we CAN'T destroy such silly things at the moment
06:27:48 <ehird> due to how the market is
06:27:55 <ehird> if we were in a position to, absolutely
06:28:07 <ehird> and, I do hope that one day it will be done, and I'd like to work on it
06:28:47 <mycroftiv> i personally feel you are making arguments that are like claiming the fonts used in a document determine the quality of the content, but i remain very interested and supportive on the meta level :)
06:29:10 <ehird> mycroftiv: theoretically, this buys you nothing in expressivity
06:29:31 <ehird> mycroftiv: but would you use a 3ghz zilog processor in lieu of, e.g. a modern Intel Xeon?
06:29:41 <ehird> there IS such a thing as a better architecture
06:29:58 <ehird> which absolutely was that to
06:30:10 <mycroftiv> i was agreeing about better architecture
06:30:23 <ehird> it's sort of like, mycroftiv,
06:30:26 <mycroftiv> i just see the chips that we have today as perfectly capable and adequate for implementing any abstractions whatsoever
06:30:27 <ehird> I could build my lisp os on top of windows
06:30:34 <ehird> I could do it and it would work
06:30:52 <ehird> the code would be god-awful, windows' overhead that concentrates on things that don't matter to my OS would slow it down,
06:30:57 <ehird> theoretically, the abstractions would be totally mismatched
06:31:03 <ehird> (and this would also lead to more bugs)
06:31:09 <ehird> (in the translation of the abstractions)
06:31:23 <ehird> now, if running it on top of windows was the only way to feasibly do it on modern computers?
06:31:28 <ehird> you bet i'd do it that way.
06:31:37 <ehird> same justification as why I'm using a regular platform
06:31:44 <ehird> instead of a superior high-level chip
06:31:53 <pikhq> mycroftiv: "Perfectly adequate", sure. So's Brainfuck.
06:32:01 <ehird> the fact is that our chips, internally, are fucking awful
06:32:08 <pikhq> That doesn't make it good, that just makes it Turing-complete.
06:32:11 <ehird> bloated piles of non-orthogonal shit, no coherent design philosophy,
06:32:14 <ehird> a bunch of 80s relics,
06:32:22 <ehird> and designed to run code from an imaginary language
06:32:22 <mycroftiv> pikhq: if someone had done the incredible amount of work to build a high level environment ON TOP of brainfuck, then brainfuck would be just fine - and isnt that the situation with our current chips?
06:32:26 <ehird> sort of a hybrid of C and crazy
06:32:35 <ehird> they really aren't "adequate", abstraction wise
06:32:40 <ehird> you seem to be a software guy
06:32:43 <ehird> so you might just not know this
06:32:48 <pikhq> mycroftiv: ... Someone has.
06:32:58 <ehird> mycroftiv: see, those layers are only required BECAUSE of the underlying system
06:33:04 <ehird> with a high-level chip, there would be far less layers
06:33:12 <pikhq> How's GCCBF going, anyways?
06:33:13 <mycroftiv> yup im 100% a software guy, thats why im kinda baffled by your perspective, because ive never had the hardware seem to interfere with anything i wanted to do
06:33:14 <ehird> and the only layers would be consistent, logical, sane ones directly related to the abstraction as hand
06:33:30 <ehird> not a leaning tower of pisa of mismatching abstractions and doing shit pointlessly in software
06:33:37 <pikhq> mycroftiv: It's primarily an issue for OS and compiler authors.
06:33:47 <mycroftiv> see, i guess i see software as *about* building abstractions
06:33:48 <pikhq> But it's a *very* important issue there.
06:33:57 <mycroftiv> i honestly want very little done *for* me - i want to build the abstractions myself!
06:33:59 <ehird> mycroftiv: see, we're using different definitions of abstraction
06:34:08 <ehird> When I refer to abstraction in a bad sense, I mean a pointless layer over something
06:34:13 <mycroftiv> ehird: that may well be true, abstraction is a pretty abstract concept
06:34:18 <ehird> as in, we have a perfectly good possibility for a layer X
06:34:24 <ehird> but instead, we take a distinctly inferior one X0
06:34:28 <ehird> and layer on top of it, X1
06:34:31 <pikhq> (other authors can build on top of the software that abstracts away most shitty things about the system)
06:34:34 <ehird> the combined system works basically as well as X
06:34:40 <ehird> but is klunky, distinctly inferior, almost certainly slower, ...
06:34:53 <ehird> that's the kind of bad "dystraction" we have in today's chips
06:35:36 <mycroftiv> pikhq: yes, and since we have done that work, and we have lots of compilers and languages available - havent we gotten past the 'hard part', so to speak?
06:35:44 <ehird> mycroftiv: look, same argument:
06:35:47 <ehird> why not build things on windows
06:35:53 <ehird> a lot of people have worked to build a whole system on top of it
06:35:57 <ehird> and there's a lot of stuff on it
06:36:13 <ehird> mycroftiv: let me know when you've switched to developing on windows.
06:36:34 <mycroftiv> ehird: well, im perfectly happy running plan 9 in qemu on windows, or using windows drawterm...so in that sense, im already there
06:36:46 <pikhq> mycroftiv: You don't *need* to care because of that work, but that doesn't make what you're using any better.
06:36:59 <pikhq> It just makes it more tolerable because you can pretend the bad shit isn't there.
06:37:02 <mycroftiv> pikhq: but the improvements can all be done at the upper layer
06:37:03 <ehird> i have a feeling there's no way I could demonstrate why chips are really really shitty without you turning into a lower level guy, mycroftiv
06:37:12 <pikhq> ... No, you can pretend that they have been done.
06:37:20 <ehird> and probably only with a better lisp chip in my hand, unless you get really serious about that sort of stuff
06:37:25 <ehird> alas that will not happen any time soon
06:37:28 <ehird> ASICs are expensive and such
06:37:31 <mycroftiv> ehird: i dont disagree that chips are shitty - but other people have done the hard work of making environments that allow *anything* to happen on top of them, without worrying about those layers
06:37:49 <ehird> mycroftiv: So fucking what? Why are these pointless layers so sacred?
06:37:54 <pikhq> mycroftiv, that *doesn't make the status quo any better*.
06:37:57 <ehird> If we don't need them, if we can do without them,
06:38:00 <pikhq> It just makes it tolerable.
06:38:03 <mycroftiv> ehird: they arent sacred, they just dont interfere with anything so far as i can tell
06:38:04 <ehird> If we can run faster, cooler running,
06:38:13 <ehird> More theoretically elegant chips,
06:38:15 <ehird> WITHOUT these layers
06:38:22 <ehird> then WHY do we see them as an argument in favour of the platform that has them?
06:38:24 <pikhq> "Don't interfere with anything"?
06:38:37 <ehird> mycroftiv: let me just tell you, they do interfere
06:38:40 <ehird> I'm dreading writing my OS
06:38:43 <mycroftiv> pikhq: well, i love this channel because normally im the critic of the status quo, advocating use of an OS most people cant stand
06:39:04 <ehird> x86_64 is like a personal vendetta against everything I want my OS to do
06:39:16 <ehird> and I have to fight it
06:39:17 <mycroftiv> ehird: how does the chip im using prevent me from writing whatever software i want? thats what i dont understand
06:39:22 <pikhq> ... If you'll note, C is still in use, because it's the best language for interacting directly with the hardware *we have* (... modulo the bloody string library).
06:39:28 <ehird> It doesn't, theoretically, mycroftiv.
06:39:32 <ehird> mycroftiv: stop using C
06:39:35 <ehird> start using machine language, directly
06:39:42 <ehird> It doesn't prevent you from writing whatever software you want
06:39:45 <mycroftiv> why would i want to throw away those layers?
06:39:46 <ehird> so why are you proposing this mystical... "C"?
06:39:50 <pikhq> mycroftiv: It doesn't prevent you, it just makes it a royal fucking pain to do certain things.
06:40:03 <pikhq> Like... Any operating system at all.
06:40:36 <pikhq> x86 OS development is significantly worse than Brainfuck coding. Brainfuck is at least consistent.
06:40:45 <ehird> if mycroftiv says the same thing again this conversation is officially killed by the hardware-based Stupid Looping Conversation Killer
06:41:14 <pikhq> x86 has pointers packed in structs by splitting the damned things into three chunks of different size.
06:41:35 * ehird resists the temptation to call his string type Bs for bytestring
06:41:36 <pikhq> (that is one of the *less* awful examples; dealing with that is at least a short function of bit twiddling)
06:41:41 <ehird> (str prefix is taken by stdlib :-P)
06:41:56 <mycroftiv> well, the whole conversation was based on a misunderstanding i guess - i thought we were talking about new chips enabling benefits for end users, by allowing for better software to be developed
06:42:04 -!- pingveno has joined.
06:42:12 <mycroftiv> if the only question is the benefits to OS writers and compilers, i never would have had any questions or disagreements
06:42:17 <ehird> mycroftiv: I think that the end result is, perhaps not the actual software is better,
06:42:21 <pikhq> mycroftiv: It allows for better *operating systems* to be developed.
06:42:36 <mycroftiv> well, i believe better OSes == better software
06:42:41 <pikhq> And that has a tendency to make everything else run better because the OS is less bad.
06:42:55 <ehird> Runs better = smoother, with less crashes, less pointless layers, faster, ... AND IS MORE THEORETICALLY ELEGANT
06:43:04 <ehird> you say that "well, that's irrelevant because the other platform has extra layers"
06:43:13 <ehird> the point is that the alternative doesn't REQUIRE those layers
06:43:19 <mycroftiv> so, you think the reason modern OSes pretty much all suck is that the chips force them to, by forcing them to push C style semantics up into layers it doesnt belong?
06:43:20 <ehird> so that's not valid
06:43:26 <ehird> then add up theoretical elegance + the benefits?
06:43:34 <ehird> not entirely, though
06:43:47 <ehird> (did we ever say that?.)
06:43:54 <mycroftiv> no, im trying to understand what you mean
06:44:06 <mycroftiv> because im trying to formulate an expression of your thesis
06:44:14 <mycroftiv> which i have yet to really understand, hence all the questions
06:44:15 <ehird> IRC seems to me to be a fundamentally bad medium for debate.
06:44:31 <mycroftiv> bring on the broken beer bottles and spiked baseball bats in an alley!
06:44:43 <ehird> You have to rush to state your arguments, debate quickly goes off track with rapid-fire messages, it can get emotional due to the real-time nature, etc...
06:44:47 <mycroftiv> im ready for the procedural vs. functional rumble
06:44:56 <ehird> nobody likes procedural. :)
06:45:05 <ehird> you don't count as a person, then.
06:45:07 <mycroftiv> its the only model i actually have ever been able to learn to think in
06:45:15 <mycroftiv> everything else i have to 'force' my brain into
06:45:29 <mycroftiv> but 'follow a set of instructions in order, like following a recipe' - ive understood that since age 5
06:45:59 <ehird> it's a model suitable for trivial recipes
06:46:05 <ehird> and instructions to 5 year olds.
06:47:20 <mycroftiv> i actually started to learn church's lambda stuff at around that age also, because my grandfather taught math and he had a game called T U F that was a proof-making game you played with dice
06:47:32 <mycroftiv> and in retrospect, i realize it was actually teaching that
06:47:54 <ehird> this conversation is kinda going nowhere
06:48:20 <mycroftiv> sorry for trying to understand your ideas, my friend
06:48:25 <mycroftiv> not trying to be offensive about it
06:48:43 <ehird> when did I say anything about that
06:49:00 <ehird> I was just saying that, based on my whole-lifetime experience of this conversation, it's unlikely to lead anywhere
06:49:37 <mycroftiv> well, any time that you feel you have wasted, i offer to refund to you in whatever form you like
06:49:42 <pikhq> mycroftiv: Do you know Haskell?
06:50:08 <mycroftiv> pikhq: ive studied it and played with it a bit, i wouldnt presume to claim i 'know' it the same way i know the languages i do say i know
06:50:35 <mycroftiv> i just find it difficult to convert from the algorithms in my head to a haskell formulation
06:50:40 <pikhq> Though it's hard to pick up (simply due to being markedly different from everything else you likely know), it makes it rather easy (compared to just about anything else) to grok functional programming.
06:51:35 <mycroftiv> i study math as much as i can, and sadly my brain handles f(g(x)) ok, but then e(f(g(x))) - and its gone
06:52:15 <mycroftiv> and i find that it seems like you are supposed to be able to track even more x of y of z of alpha of beta..than that
06:52:29 <mycroftiv> so its a bit of a cognitive wall for me
06:52:35 <pikhq> mycroftiv: Instead of saying "int sum (int *array; int size) {int sum;for (int i = 0; i < size; i++) sum += array[i]; return sum;}", you just do "sum = map (+)"
06:52:51 <ehird> mycroftiv: maybe you should augment your memory :)
06:52:52 <pikhq> That is to say, you don't say *how* you do something, but rather *what you want done*.
06:53:11 <mycroftiv> i have my own library of that kind of stuff i wrote for myself in C
06:53:12 <ehird> mycroftiv: Figure this out:
06:53:27 <pikhq> Incidentally, "e . f . g" is not much harder than "f . g" ;)
06:53:31 <ehird> sum xs = fold (+) xs
06:53:42 <ehird> So, we have a list [1,2,3] right?
06:54:20 <ehird> mycroftiv: given the list [1,2,3], and addition, what syntactic change can we make to it to sum it?
06:54:26 <ehird> like, [1,2,3]; you have a + sign
06:54:31 <ehird> how do you turn it into the sum of [1,2,3]?
06:54:42 <pikhq> ... Also, "map (+)" is made of fail. That makes a list of functions, and... Yeah. Totally wrong.
06:55:21 <mycroftiv> are you just talking about fold (+) [1, 2, 3] ?
06:55:39 <ehird> mycroftiv: I'm trying to explain folding in terms of functional languages
06:55:48 <ehird> as in, how you model operations non-iteratively
06:55:56 <ehird> you can make syntactic changes to it
06:56:14 <ehird> what transformation do you do to [1,2,3] using + to turn it into the sum?
06:56:23 <ehird> you get rid of the brackets
06:56:26 <ehird> and replace , by +
06:56:34 <ehird> that's, basically, what fold does
06:56:42 <ehird> product is fold (*), then
06:57:00 <ehird> fold itself is built as a recursive function
06:57:06 <ehird> but in high level haskell, you don't generall recurse
06:57:13 <mycroftiv> why are you explaining these basics to me? im not ignorant, i just said my brain doesnt seem to naturally think in functional terms
06:57:17 <ehird> you use simple combinators like that to build up a transformation of data
06:57:24 <ehird> mycroftiv: It's not what fold is itself
06:57:29 <ehird> That's not what I'm trying to get across
06:57:36 <ehird> I'm trying to get across how to apply the functional mindset to it all
06:58:42 <mycroftiv> do you know the borges story "Tlon, Uqbar, Orbit Tertius" ?
06:59:16 <mycroftiv> well, to cut directly to the point - alternate universe where people dont think in nouns, they only think in verbs/perceptions
06:59:41 <mycroftiv> when i learned about functional programming it was like that story had come to life and i was amazed
06:59:44 <ehird> that's the opposite of functional programming, really
06:59:51 <ehird> functional programming is all about the data
07:00:26 <pikhq> Imperative programming is a series of verbs.
07:00:38 <ehird> The internet is a series of verbs.
07:01:27 <pikhq> Functional programming is, ultimately, a piece of data, and what you write is transformations on other pieces of data in order to arrive at your final piece of data.
07:01:37 <pikhq> Oh, and functions themselves are data.
07:01:50 <pikhq> (which, of course, means you can do transformations on your functions)
07:02:03 <mycroftiv> i absolutely believe lisp has the best and clearest model of programming
07:02:51 <ehird> he never said lisp
07:02:54 <pikhq> ... Lisp is a hacky and low-level language, in my estimation.
07:02:58 <ehird> common lisp in fact is not a functional programming language in the slightest.
07:03:09 <ehird> "yes," doesn't follow then
07:03:16 <ehird> i'm doing fun stuff!
07:03:19 <ehird> you will see soon.
07:03:54 <mycroftiv> 'functions themselves are data' was the sole referent of 'yes, i do love lisp' - by which i meant 'i agree that the model where functions are data is the best, based on my appreciation of lisp'
07:04:45 <ehird> I am warming more to lisp lately
07:04:50 <mycroftiv> see i dont want you guys to think that i dont *agree* with you - im just more skeptical that the Data Paradise can actually be brought about
07:04:52 <ehird> a bastardised, ehird lisp
07:05:00 <ehird> but a lisp nonetheless
07:05:13 <pikhq> mycroftiv, it was done a few decades ago.
07:05:18 <ehird> mycroftiv: I have modelled actions successfully in my domain
07:05:19 <mycroftiv> i *agree* with all the stuff you say, but i think that even if you make better chips and OSes and everything...software will still probably mostly suck
07:05:20 <pikhq> Are you familiar with Lisp machines?
07:05:24 <ehird> they have turned out succ—
07:05:30 <ehird> they still had filesystems
07:05:35 -!- kar8nga has joined.
07:05:39 <ehird> (which stored the code files)
07:05:42 <pikhq> ehird: True. Still...
07:05:43 <mycroftiv> pikhq: not personally, ive just read about them, i grew up on the home computers of the 80s starting in 1980 and i never had any access to anything else
07:06:01 <ehird> mycroftiv: the whole point of my OS is that I think I know how to make software not suck
07:06:10 <ehird> as a fundamental model
07:06:13 <pikhq> mycroftiv: Less suck than modern OSes.
07:06:56 <mycroftiv> pikhq: since i hate all modern OSes except plan 9, no argument from me on that.
07:07:07 <ehird> plan 9 is still loatheful
07:07:27 <mycroftiv> ehird: no way, it has namespaces, which are Just Exactly Right, imo
07:07:38 <ehird> disk/ram namespaces are separate
07:07:56 <mycroftiv> you can build your namespace however you want
07:07:57 <ehird> if you think they aren't
07:08:01 <pikhq> That's kinda the C model.
07:08:02 <ehird> you misunderstood my comment entirely.,
07:08:16 <mycroftiv> in plan 9 your namespace knows nothing about ram vs disk
07:08:17 <ehird> also, the functions in the OS are distinctly inferior to the functions in the language
07:08:20 <ehird> being untyped affairs
07:08:23 <ehird> mycroftiv: no, no, listen
07:08:34 <ehird> it has in-memory addresses
07:08:40 <ehird> foo->bar->baz in C
07:08:43 <ehird> and it has filesystem addresses
07:08:52 <ehird> these two concepts being distinct is evil
07:09:05 <ehird> and a cause of many, many woes present in computing today
07:09:26 <mycroftiv> thats not what namespaces are in plan 9 though, we are at different layers, as usual
07:09:32 <ehird> we're at same layers
07:09:36 <ehird> you are just using different definitions
07:09:47 <ehird> and trying to rebut the arguments I made with my definitions, with yours...
07:09:57 <mycroftiv> im using namespace as defined/used in the context of the plan 9 operating system and its manpages, thats all
07:10:29 <mycroftiv> simply talking about its implementation of per-process namespaces, which is a great feature - i totally agree that ultimately the different modes of addressing data between filesystem and programming languages is Bad
07:10:29 <pikhq> And he's discussing from a programming perspective, not from the perspective of someone using, say, rc.
07:10:38 -!- coppro has quit (Remote closed the connection).
07:10:46 <ehird> if plan 9 just had rc and C i could respect it
07:10:55 <ehird> though it'd be shit, as all it'd have would be weakling string types.
07:11:04 <ehird> ...there's a reason c has a richer type system :)
07:11:12 <mycroftiv> pikhq: i program plan 9 in C, i understand the point he is making
07:11:15 <pikhq> ehird: Weakling string types doesn't necessarily make for a bad language. See Tcl.
07:11:24 <ehird> pikhq: we will have to strongly disagree.
07:11:57 <pikhq> (... Though, Tcl does it via magic, so it's not exactly a *grand* language. And that's probably about as good as you can get while retaining "everything is a string".)
07:12:16 <ehird> rc is a nice language. for scripting.
07:12:22 <ehird> uh, wouldn't want to program a whole system in it.
07:12:33 <ehird> yet the "language" of plan 9 has exactly the same semantics, and it still has C
07:12:41 <ehird> ... no coincidence: C's semantics are, in fact, nicer to code in
07:12:45 <ehird> than the language of Plan 9's
07:12:51 <ehird> and its separate namespace hierarchy
07:12:58 <ehird> with silly, untyped strings
07:13:38 <mycroftiv> ehird: you arent using vocabulary in the way plan 9 does, so its very hard for me to parse your statement...
07:13:53 <ehird> i wasn't aware plan 9 brainwashed its adherents :)
07:14:04 <ehird> namespace: a space containing identifiers
07:14:11 <ehird> e.g. in C, a->b->c is a member of its namespace
07:14:19 <pikhq> He's using it the way anyone sane (and most insane people) use it.
07:14:25 <ehird> in Plan 9, /a/b/c would be an example
07:14:25 <mycroftiv> all along, i was trying to talk about namespaces in the specific plan 9 sense, that is all
07:14:38 <ehird> Plan 9's is distinctly inferior because:
07:14:41 <mycroftiv> pikhq: yes, but in plan 9, 'namespaces' have a much more OS context specific meaning, which is what i was trying to talk about
07:14:52 <ehird> the names can only identify typeless strings of bytes
07:15:02 <ehird> C's namespace can identify all sorts of richer things
07:15:12 <ehird> rc is an example of a language built around the semantics of Plan 9's namespaces
07:15:20 <ehird> C is an example of a language built around the semantics of C's namespaces
07:15:32 <ehird> there's a reason why most of plan 9 is written in C, not rc: C is nicer for non-scripting things
07:15:38 <ehird> and this is because of its richer namespace.
07:15:53 <ehird> in my OS, there is only one namespace, and it is a rich, object-based one, like Smalltalk
07:17:46 <pikhq> (exception: Forth. (but there be dragons there, and you can pretend that that is entirely imaginary))
07:18:08 <ehird> pikhq: I'm not referring to the languages
07:18:18 <ehird> and forth is basically a bootloader in my os :P
07:18:29 <ehird> the thing is that most languages are both a namespace and a language based on that namespace
07:18:29 <pikhq> Tiny bit more complicated than a bootloader.
07:18:38 <ehird> with plan 9 it's separate: namespace:plan 9, language:rc
07:18:42 <ehird> so it's harder to discuss it
07:18:44 <pikhq> I guess the closest thing it would be (and it's not exactly *close*) is a kernel?
07:18:47 <ehird> because people don't see it as a language
07:18:52 <ehird> it's not centralised anything
07:18:56 <ehird> it just executes the upper code
07:19:07 <ehird> no hardware or anything
07:19:19 <ehird> it doesn't have a name in the common vernacular. :)
07:19:42 <pikhq> Like I said, it's not exactly close.
07:21:03 <ehird> pikhq: my secret project, by the way, is an IRC bot scriptable in C
07:21:21 <ehird> you can do !eval say(channels[0], "hello world")
07:21:27 <ehird> it turns out that gcc -c is fast
07:21:37 <ehird> so kinda-JITting C is perfectly possible
07:21:40 <ehird> as long as you don't link
07:21:59 <ehird> ...but also some fun other stuff.
07:27:15 <ehird> ofc, I have to somehow open this object file without linking it
07:27:21 <ehird> which could be uh tricky
07:28:34 <ehird> ooh, linking a shared lib is actually fast
07:29:02 <ehird> [ehird:~/Code/cbot] % time ./dynamic '2' >/dev/null
07:29:02 <ehird> ./dynamic '2' > /dev/null 0.02s user 0.02s system 94% cpu 0.048 total
07:29:56 <ehird> now all I have to do is implement a dlopen that latches on to another process so I can access the bot from the snippet...
07:48:10 <ehird> % ./dynamic 'int j;for(int i=0;i<1000;i+=3)j+=i;j'
07:48:14 <ehird> yep, that... works
07:57:59 -!- oerjan has joined.
07:59:59 -!- clog has quit (ended).
08:00:00 -!- clog has joined.
08:13:01 -!- pingveno has quit (Read error: 104 (Connection reset by peer)).
08:23:36 -!- M0ny has joined.
08:25:18 -!- kar8nga has quit (Remote closed the connection).
08:44:01 -!- oerjan has quit ("It's no laughing matter!").
09:03:43 -!- ehird has quit.
09:41:33 -!- Gracenotes has quit (Read error: 60 (Operation timed out)).
10:38:32 -!- FireFly has joined.
10:41:42 -!- MigoMipo has joined.
11:01:29 -!- BeholdMyGlory has joined.
11:05:16 -!- M0ny has quit.
11:18:04 -!- MigoMipo has quit.
11:31:56 -!- BeholdMyGlory has quit (Remote closed the connection).
11:32:12 -!- BeholdMyGlory has joined.
12:14:50 -!- Pthing has joined.
12:27:28 -!- MigoMipo has joined.
13:16:50 -!- MigoMipo has quit.
14:10:11 -!- ais523 has joined.
14:11:21 -!- MigoMipo has joined.
14:25:11 -!- puzzlet_ has joined.
14:25:12 -!- puzzlet has quit (Remote closed the connection).
15:07:09 -!- Asztal has joined.
15:20:50 -!- MigoMipo has quit ("fe'o rodo").
15:35:51 -!- kar8nga has joined.
16:19:23 -!- puzzlet_ has quit (Read error: 104 (Connection reset by peer)).
16:51:59 -!- puzzlet has joined.
17:03:12 -!- kar8nga has quit (Remote closed the connection).
17:06:33 -!- lifthrasiir has quit (Read error: 145 (Connection timed out)).
17:21:35 -!- oerjan has joined.
17:35:07 -!- lifthrasiir has joined.
17:36:40 -!- lifthrasiir has quit (Remote closed the connection).
17:42:34 -!- puzzlet has quit (Read error: 104 (Connection reset by peer)).
17:51:50 -!- lifthrasiir has joined.
17:58:21 -!- puzzlet has joined.
18:01:02 -!- Gracenotes has joined.
18:01:56 -!- Gracenotes has quit (Remote closed the connection).
18:02:42 -!- Gracenotes has joined.
18:29:47 -!- ehird has joined.
18:29:51 -!- ais523 has quit (Remote closed the connection).
18:34:05 <oerjan> yet another weariness noun
18:41:51 -!- ehird has quit.
18:44:52 -!- pingveno has joined.
19:09:25 -!- M0ny has joined.
19:28:25 -!- Gracenotes_ has joined.
19:31:24 -!- coppro has joined.
19:43:32 -!- Gracenotes has quit (Nick collision from services.).
19:43:37 -!- Gracenotes_ has changed nick to gracenotes.
19:51:44 <oerjan> ding, dong, the channel's dead
19:52:38 * coppro ding's the channel's don
19:53:16 <oerjan> you donna wanna messa with the channel's don
20:14:23 -!- coppro has quit (Remote closed the connection).
20:31:13 -!- coppro has joined.
20:39:09 -!- pingveno has quit (Remote closed the connection).
20:49:18 -!- CESSMASTER has quit (wolfe.freenode.net irc.freenode.net).
20:49:18 -!- SimonRC has quit (wolfe.freenode.net irc.freenode.net).
20:50:56 -!- CESSMASTER has joined.
20:50:56 -!- SimonRC has joined.
20:51:00 -!- CESSMASTER has quit (Connection reset by peer).
20:52:05 -!- SimonRC has quit (Read error: 54 (Connection reset by peer)).
20:52:06 -!- SimonRC_ has joined.
20:53:54 -!- CESSMASTER has joined.
21:17:59 -!- GreaseMonkey has joined.
21:37:17 -!- M0ny has quit.
21:51:34 -!- GregorR_ has joined.
21:56:53 -!- BeholdMyGlory has quit (Remote closed the connection).
21:57:13 -!- GregorR has quit (Read error: 110 (Connection timed out)).
22:52:46 -!- sebbu2 has joined.
23:03:59 -!- gracenotes has changed nick to Gracenotes.
23:04:12 -!- FireFly has quit ("Later").
23:07:06 -!- nescience has quit (Read error: 60 (Operation timed out)).
23:10:05 -!- sebbu has quit (Read error: 110 (Connection timed out)).
23:11:31 -!- poiuy_qwert has joined.
23:54:00 <coppro> I think I just noticed the subletest joke I've ever noticed in a Discworld book