00:01:02  * sorensen__quit (Quit: Leaving...)
00:05:51  * tm604joined
00:45:07  * dominictarrjoined
00:50:36  <dominictarr>hey guys
00:52:03  <dools>yo
00:52:18  <dominictarr>hey dools whats up?
00:54:14  <dominictarr>dools are you still doing php? when are you gonna switch to node.js?
00:54:42  <dools>when i can go on odesk and find 230,000 node.js developers
00:54:53  * SubStackin fremont
00:55:15  <SubStack>s/developers/opportunists/
00:56:12  <dools>is that what the node.js community calls developers?
00:56:47  <SubStack>well I mean php and java are overrun with people who just learn it so they can get a job
00:56:54  <SubStack>but there isn't much passion
00:56:55  <dools>shame on them
00:57:02  <SubStack>so you don't get as much mad science
00:57:08  <dools>i don't need passion, i need mechanical labour
00:57:35  <dools>there is plenty of passion in php anyway
00:57:48  <dools>all open sourced, so i can use it :)
00:58:33  <rowbit>Hourly usage stats: [free: 21]
00:59:44  <dominictarr>dools: fair point.
00:59:59  <dools>there's always room for R&D off of the critcal path :)
01:01:25  <dominictarr>in 10 years there will be a billion mexican street kids who know js.
01:01:45  <dools>sign me up
01:02:03  <dools>yeah i saw this guy tweet "wow i want my kids to learn how to code" or some shit
01:02:21  <dools>i was like "i want my kids to learn how to code about as much as i want them learning how to lay bricks because that's the future of it"
01:03:16  <dominictarr>what do you mean, that it will be menial labor?
01:03:35  <dools>yeah
01:03:47  <dools>computer *science* is a different story of course, but so is materials science
01:04:06  <dools>the notion everyone as that all kids must learn to code now i think is pretty myopic
01:04:10  <chapel>well laying bricks is not as wide spread as you think
01:04:18  <chapel>just because anyone can do it, very few do
01:04:43  <chapel>so as with programming, even if most people learn it, only few will actually do it for a living
01:04:46  <dominictarr>100-200 years ago people would have said that about learning to read.
01:04:54  <chapel>it will never be the mcdonalds job I don't think
01:05:21  <dools>that's just because software production hasn't had time to get to the point where it can be like mcdonalds
01:05:34  <dominictarr>a farm boy doesn't need to know how to read.
01:05:59  <dools>PENIS
01:06:03  <dools>sorry my tourettes playing up
01:06:15  <dools>where's loudbot?
01:06:29  <dominictarr>for things like that, crudely drawn pictures is sufficant.
01:06:35  <dools>hahaha
01:06:44  <dools>3===> like that?
01:06:56  * wiwilliaquit (Ping timeout: 250 seconds)
01:07:03  <dominictarr>that one is a bit pointy.
01:07:10  <dominictarr>8=====D
01:07:16  <dools>haha yeah that's a much nicer porn cock
01:07:20  <dominictarr>mine's longer.
01:07:25  <dools>mine would never get hired
01:07:27  * jeffbcrossjoined
01:07:34  * jeffbcrossquit (Client Quit)
01:07:38  <dools>"hmm you've got moxie kid but your johnson's too pointy"
01:08:20  <dominictarr>okay, that is the funniest thing so far today.
01:08:40  <dools>ke ke ke
01:11:29  <dominictarr>but we digress, there is still a lot more intelect in even the most menial coding than there is in making a burger. especially a macdonalds burger.
01:14:25  * ryan_stevensquit (Quit: Leaving.)
01:15:06  <dools>mcdonalds had to invest a lot in systems to normalise the burger production process in order to widen their hiring pool sufficiently so they can pay people $5 an hour to make burgers. the same is possible with programming, especially when coding becomes as common as reading
01:15:29  <dools>and given we're not encumbered by physical constraints (ie. i can easily hire 1 of the billion mexican js kids)
01:16:18  <dominictarr>yeah, but if you just need to put the thing together the same way each item, you can do that with a script.
01:16:34  <dominictarr>you only need to hire one person.
01:18:20  <dominictarr>the most menial programming is where companies need bespoke customization.
01:19:05  <dominictarr>(even if that is just wordpress themeing)
01:20:07  <dominictarr>I guess if regular people started buying those services it might create a market like that.
01:20:23  <dools>i don't think the analogy holds up like "assembling a burger is like deploying your application"
01:20:53  <dools>it's not about analogising to what type of product or customer you have, it's the process of creating systems and processes that allow you to widen your hiring pool to reduce costs
01:21:08  <dools>and not allowing value to aggregate in people
01:21:39  <dominictarr>oh. yes maybe your right.
01:21:54  <dominictarr>so how would you do that in software?
01:22:06  <dools>well! THAT'S what i'm working on ;)
01:22:31  <dominictarr>with decal?
01:23:41  <dools>partly yes, that's certainly provided the genesis but moreover i'm just working on outsourcing generally
01:27:15  <dominictarr>ah, interesting.
01:29:21  <dominictarr>what is your approach to out sourcing?
01:29:49  <dools>it's kind of involved, i just sent you an email with a whiteboard i wrote up on it
01:38:18  <dominictarr>this is interesting. it is possible to build systems that are more reliable than their components.
01:38:25  <dominictarr>like the internet.
01:38:30  <dominictarr>or phone network.
01:39:02  * isaacsquit (Remote host closed the connection)
01:39:40  * _ritch1quit (Quit: Leaving.)
01:41:41  <dominictarr>I've been thinking about a system that is kinda on vibe with this, but it's pretty mad science.
01:41:47  <dominictarr>basically,
01:42:48  <dominictarr>the idea is that if you can write sufficantly precise tests, the compiler should be able to write the product code for you.
01:58:32  <rowbit>Hourly usage stats: [free: 19]
02:02:30  <dools>re: internet/phone also RAID is the best analogy i've thought of
02:02:43  <dools>only i thought of Redundant Array of Inexpensive People
02:02:53  <dools>but i can't see too many people putting RAIPist on their business card
02:22:20  * isaacsjoined
02:24:25  <dominictarr>yeah, the thing that makes those systems reliable is redundancy. if that was to work with software... I think it would mean that you would have separate teams implement the same thing in parallel
02:24:29  <dominictarr>producing bugs.
02:24:34  <dominictarr>different bugs
02:25:36  <dominictarr>then you would need a way to select which version you would use, or which system to send users to.
02:25:53  <dominictarr>this is pretty on vibe with the lean startup.
02:26:02  <dools>that's what i thought at first although you quickly approach first world wages doing it that way
02:26:40  <dools>i've found the most effective way to increase redundancy is to not care about the output, split a job up into several discrete chunks and have a large pool of potentially available people to work with
02:27:08  <dools>"a constant process of draft and review"
02:27:42  <dominictarr>redundancy means to have a fallback.
02:28:13  <dools>yeah so in terms of a software project, right imagine the traditional way of doing things where you have "a developer" taht you've hired and invested training in. he's YOUR MAN
02:28:20  <dools>you're not beholden to his schedule and reliability
02:28:22  <dools>if you have a job
02:28:29  <dominictarr>this idea would work for the front end, but you would need to make sure they don't break your data. i.e. validation.
02:28:36  <dools>and you can manage to split that job up into 9 equal parts which require no communication between each person
02:29:08  <dominictarr>but, YOU can only do that because you are a smart developer.
02:29:11  <dools>then if 3 of them don't succeed, you've still got 6/9 of the work done and you can get 3 of your guys that did do the work, to complete those three units. so you lose a little schedule, but it's far less 'binary' in terms of the way it fails
02:29:25  <dominictarr>oh right.
02:29:27  <dools>ah yes, SO the next thing is that this is not a tool for non-technical people to use
02:29:36  <dools>this is a tool to multiplex the hours of one talented developer
02:30:29  <dominictarr>oh right, so each worker would need some way to know if what their thing does is actually right.
02:30:40  <dominictarr>how do you handle that?
02:31:04  <dominictarr>I mean, any one could churn out some code. need something to test it against.
02:31:26  <dominictarr>if the team is in close communication they test it against each other.
02:32:02  <dominictarr>you would need to define the APIs
02:32:20  <dools>tests, but the problem there is you start to go "well, that means i need a highly skilled person to write the tests!!"
02:32:31  <dools>which just gets you back to square 1
02:32:33  <dools>really
02:32:38  <dools>so you just need *some* tests
02:32:53  <dools>we've been using murphy and so far it's working well. but the key is this:
02:33:04  <dools>think of your testing as a tool only to reduce the cost of QA
02:33:09  <SubStack>back in oak towne
02:33:49  <dools>so QA is responsible for catching bugs. you then tell your dev: write a test which fails in precisely the same way then fix the code. they do that, you do qa again, it's "fixed"
02:34:16  <dools>some percentage of the time, the dev will have gotten it wrong, but that's okay. your tests aren't there to stop all bugs, they're just there to reduce the cost of qa. qa is responsible for finding bugs
02:34:34  <isaacs>dools: at that point, why have a special "qa"?
02:34:48  <isaacs>dools: why not just write a test to reproduce every bug that gets reported to you, no matter how?
02:35:07  <isaacs>and then have devs and users do that
02:37:42  <dominictarr>I used to think that testing naturally produced more modular code.
02:37:51  <SubStack>rook2pawn: excellent
02:37:59  <dominictarr>that was certainly the effect it had on me when I started doing it.
02:38:22  <dominictarr>but I have since witnessed monolithic code that still has a lot of tests.
02:38:45  <dools>isaacs: so the relationship between testing and qa in my current methodology is this:
02:39:02  <dominictarr>using mocks, and horrible stuff like that.
02:39:11  <dools>tests are automated, and test for regressions. when a developer completes work and before pushing to the master repo, they can run tests. if something breaks, they can fix it right away. this incurs the minimum cost
02:39:20  <dools>dominictarr: fuck mocks. i'm in murphyville
02:39:32  <dominictarr>whats murphy?
02:39:39  <isaacs>as in murphy's law?
02:39:43  <dools>https://github.com/iaindooley/Murphy
02:40:01  <dools>isaacs: yeah my framework is rocketsled, murphy as in murphy's law "anything that can go wrong wil go wrong" was a rocketsled engineer
02:40:27  <dools>isaacs: when you're ready to do some sort of release, you *should* also do QA - that means using your application. outsourcing has a dramatic effect on the ecomonics of this. the job of QA is to catch bugs. this is the most expensive way to fix bugs
02:40:39  <dools>so the goal of automated testing is to reduce the cost of QA
02:40:54  <dools>whether or not its the same people fulfiling the roles or not makes no difference - they're still separate roles
02:41:20  <isaacs>sure, but... it's all about cost/benefit
02:41:33  <isaacs>for something like node, or npm, or a website, fuckit. just release bugs. i mean, don't *try* to
02:41:37  <isaacs>and dogfood the hell out of it
02:41:49  <dools>sure that's just your qa then right?
02:41:56  <isaacs>but have tests, and use that as a rachett, and fix bugs as they come up
02:42:13  <dominictarr>I think dools wants to not rerelease bugs.
02:42:18  <isaacs>you are my QA :)
02:42:19  <dools>yeah so the goal of those tests is to reduce the "cost" of qa. if you're not doing qa (ie. paying someone for it) you're incurring community cost
02:42:26  <dools>dominictarr: precisely
02:42:26  <isaacs>dominictarr, dools: but, you WILL release bugs!
02:42:29  <isaacs>the question is how big are they?
02:42:32  <dools>isaacs: re-release
02:42:38  <isaacs>oh, re-release
02:42:39  <isaacs>right
02:42:40  <isaacs>well, sure
02:42:43  <isaacs>that's what tests are for
02:42:45  <dools>my goal is not to produce bug free code but to fix each bug once
02:42:58  <isaacs>dools: sometimes, even with testing, though, you fix the same bug multiple times
02:43:03  <dools>yes
02:43:07  <isaacs>dools: especially if you make all your fixes surgical
02:43:10  <dools>so some percentage of the time tests are wrong
02:43:15  <isaacs>even right tests
02:43:18  <dools>yes
02:43:20  <dools>absolutely
02:43:39  <isaacs>if you have some architectural issue that you patch your way out of bit by bit, it ends up being much more costsly sometimes than just scrapping it, with the tests, adn re-doing it
02:43:46  <dools>so when i speak about my model to people, and i say "i just get developers to write tests, if they pass they pass, i glance at them but the same people writing the code write the tests"
02:43:56  <dools>they start to say "oh, but then you need an in-house guy to write the tests"
02:44:14  <isaacs>what is this "house" stuff? ;P
02:44:16  <dools>but my answer to that is, that tests only have to be "right" some percentage of the time, you can outsource your QA very cheaply
02:44:24  <SubStack>mocks are good for not getting paint on your clothes
02:44:29  <isaacs>hahah
02:44:36  <dools>haha smock objecdts
02:44:37  <isaacs>SubStack: i think yoer' thinking of "smocks"
02:45:06  <SubStack>no that's when you hit somebody with the palm of your hand
02:45:24  <dools>isaacs: so the reason i'm saying "qa is for catching bugs" is because, when i say to people "it doesn't matter if the tests are right" they go "but what about teh bugs!"
02:45:56  <isaacs>dools: tell them that you only fix the bugs that are more costly to have than to fix.
02:46:16  <SubStack>qa is for saving you time verifying that the thing works and for catching regressions automatically
02:46:24  <SubStack>or tests I mean
02:47:42  <SubStack>rook2pawn: sweet api for node-intersect
02:47:55  <SubStack>you could also get it running under travis-ci
02:49:49  * SubStackhacks on node-trotsky
02:50:18  <dominictarr>lean startup describes an interesting system where it reverts changes that produce bad business metrics.
02:50:46  <dominictarr>so like a change that hides a signup button will not get run
02:50:57  <dominictarr>for very long.
02:51:00  <SubStack>one problem is that it takes a LOT of data to get to statistical significance
02:51:19  <SubStack>a big site can get enough data in a few hours but for a smaller one it could take months
02:51:22  <dominictarr>yes. that option is not available to the long tail
02:51:38  <dominictarr>a very interesting idea non the less.
02:51:51  <SubStack>for a big site you could do it on every commit
02:52:07  <SubStack>well, every commit that gets deployed
02:52:17  <SubStack>since not every commit should need to be deployable
02:52:46  <dominictarr>yeah. maybe deploy feature branches.
02:53:20  <dominictarr>when testing... although... but maybe you want to use one branch and do feature toggling.
02:54:25  <dominictarr>you could pay people to use your site, for testing at least you will see if it's actually functional.
02:58:38  <rowbit>Hourly usage stats: [developer: 2, free: 26]
03:02:21  <SubStack>you don't need branches for that
03:02:42  <SubStack>every time somebody deploys you can just store the commit hash
03:02:52  <SubStack>and record what the previous commit hash was too
03:03:15  <SubStack>the previous deployed commit hash I mean
03:05:23  <dominictarr>and have a stable tag and a testing tag.
03:15:06  * isaacsquit (Remote host closed the connection)
03:15:46  * isaacsjoined
03:20:02  <dominictarr>oh, no.. head is the 'testing tag'
03:22:20  * ryan_stevensjoined
03:50:07  <SubStack>dominictarr: the system I have in mind doesn't have much of a distinction between stable, testing, or staging
03:50:20  <dominictarr>ahuh
03:50:25  <dominictarr>do tell
03:50:34  <SubStack>you just push new code all the time but nobody sees it until you tell the load balancer to ratchet up
03:50:49  <SubStack>and the old stuff lives alongside the new stuff on the same servers
03:51:06  <SubStack>that's what seaport enables
03:51:55  <SubStack>since every service gets a new random port
03:52:20  <dominictarr>oh that is similar to the approach I was using
03:53:21  <dominictarr>I was thinking to have a ring of application servers which are also load balancers.
03:54:04  <dominictarr>they would need to share their list of running apps so any of them could handle any request.
03:54:25  <SubStack>yep, that's what seaport is for
03:54:46  <dominictarr>I thought seaport assigned ports?
03:54:52  <SubStack>yes
03:55:04  <dominictarr>does it also advertise what service is on what port?
03:55:06  <SubStack>and it keeps a list of all the ports it assigned and to what ip addresses
03:55:18  <SubStack>so you can ports.query('servicename', function (ps) { ... })
03:55:25  <dominictarr>oh cool.
03:55:33  <SubStack>where ps is a list of the services as { port : n, host : '...' } records
03:55:39  <SubStack>and you can also put metadata in that object
03:55:50  <SubStack>and you can query using semvers too
03:55:50  <dominictarr>I was gonna do that with a gossip protocol and keep the service list on every balancer
03:56:07  <dominictarr>so you can balance syncronously.
03:56:23  <dominictarr>I mean, immediately on recieving the request.
03:56:27  <SubStack>that's something seaport can't do quite yet
03:56:49  <dominictarr>it's overkill
03:56:52  <dominictarr>but it's cool.
03:56:54  <SubStack>well I don't think so
03:57:08  <SubStack>since I also need the same api to enable this functionality as for some other things
03:57:22  <SubStack>pretty much all I need is a .subscribe() function to listen for remote state change events
03:57:31  <SubStack>and somebody already sent me a pull request for this
03:57:37  <dominictarr>yeah, that would do it.
03:57:40  <SubStack>and then you just tell the seaport services to subscribe to each other
03:58:13  <dominictarr>when do you decide to disable the old service on an update?
03:58:19  <SubStack>and then I'll upgrade the upnode connection to use airport if you pass in a ports list
03:58:33  <rowbit>Hourly usage stats: [free: 11]
03:58:38  <SubStack>that will make fail-over automatically work dns style
03:58:44  <SubStack>because airport already supports that
03:58:54  <SubStack>and the seaports can all just register themselves through themselves
03:59:06  <SubStack>so you can query for all the seaport servers
03:59:31  <SubStack>dominictarr: the port record is valid until the upnode connection drops
03:59:57  <SubStack>and if you use ports.service() the service will attempt to re-assume the same port when the connection to the seaport server comes back online
04:00:35  <dominictarr>what does upnode do?
04:01:33  <dominictarr>what happens if you try to proxy a request somewhere but it's turns out it's down?
04:02:16  <SubStack>upnode is a wrapper around dnode that re-establishes the connection when it goes down
04:02:39  <SubStack>and queues all the requests when a connection goes down to play them back when it comes back up again
04:03:46  <SubStack>and upnode connections continuously ping the other endpoint to make sure that the connection still works
04:04:25  <SubStack>it pretty much lets you treat an unreliable network as reliable
04:04:38  <dominictarr>oh, cool.
04:05:02  <dominictarr>have you read the dynamo paper?
04:05:47  <SubStack>nope
04:05:53  <ryan_stevens>substack: does upnode have an upper bound for a queue… So if it queues requests for so long or has so many built up it can do something else. Say notify a monitoring service to escalate the issue
04:06:07  <SubStack>ryan_stevens: there's a way to do timeouts
04:06:12  <ryan_stevens>nice
04:06:26  <SubStack>up(5000, fn)
04:06:29  <SubStack>instead of up(fn)
04:06:33  <SubStack>for a 5 second timeout
04:07:09  <ryan_stevens>dominictarr: Are you thinking of implementing a sea port like thingy in a consistent hash ring?
04:07:36  <dominictarr>ryan_stevens: yes, but only thinking about it.
04:07:56  <ryan_stevens>I've been seriously considering taking parts of seaport and doing the same thing
04:07:59  <dominictarr>dynamo actually uses a plugin for the persistance layer.
04:08:06  <ryan_stevens>interesting
04:08:23  <dominictarr>it's actually not a db, it's a replication/redundancy layer
04:08:49  <dominictarr>you could easily adapt the idea to replicatie stateless services.
04:08:52  <ryan_stevens>yeah, I was more referring to that aspect of it
04:09:15  <dominictarr>sometimes they use mysql inside of it!
04:10:40  <SubStack>I think for seaport I can get away with using the Date.now() from the services to resolve conflicts
04:10:55  <SubStack>since only the services themselves modify their own state
04:11:01  <dominictarr>yeah
04:11:21  <dominictarr>have you heard of CRDTs?
04:12:27  <maxogden>cathode ray death tubes?
04:14:34  <dominictarr>Commutative Replicated Data Types
04:15:05  <dominictarr>so like, if you have a voting feature
04:15:51  <dominictarr>many users can concurrently send increments because it doesn't matter what order you apply them.
04:16:03  <dominictarr>because addition is commutative
04:17:08  <dominictarr>if you can make your changes commutative then merging things is really easy
04:17:21  <dominictarr>thats basically what your talking about
04:18:56  <dominictarr>http://hal.inria.fr/inria-00555588/en
04:22:29  <SubStack>yep
04:28:06  <dominictarr>there are even models for editing text with inserts and deletes,
04:28:10  * ryan_stevensquit (Quit: Leaving.)
04:28:25  <dominictarr>you just never really delete things though you just hide it.
04:29:55  <dominictarr>so it has to fit the domain, but it's a really easy to understand, compared to 3-way-merge or OT
04:31:11  <SubStack>data sets that do not depend on the state of other data in the same set would seem to have this property
04:31:28  <SubStack>and instead depend on external events
04:31:32  * wiwilliajoined
04:31:34  <dominictarr>correct
04:33:22  <dominictarr>as long as the order you receive doesn't matter either, provided that you eventually receive everything.
04:34:17  <dominictarr>the paper calls that a 'register'. and in pretty much the simplest case.
04:34:33  <SubStack>if only the computer could tell us when such properties exist so we can maximize laziness
04:34:52  <SubStack>our own laziness as programmers I mean, not lazy vs eager
04:35:58  <dominictarr>maybe if you wrote good enough tests, the computer could write the product code.
04:37:01  <SubStack>so I've also thought quite a lot about that problem
04:37:14  <SubStack>it's amazingly difficult
04:37:40  <SubStack>consider a program that needs to predict this sequence:
04:38:00  <SubStack>0 1 10 11 100 101 110 111 1000 ...
04:38:30  <dominictarr>the search is parallelizable, though and clouds are cheap
04:38:32  <SubStack>but all it receives is a binary stream
04:38:40  <SubStack>the search through algorithm space?
04:38:44  <dominictarr>yeah
04:38:56  <dominictarr>the program for that is pretty short-
04:39:04  <SubStack>algorithm space is really massive, I think you'd need a lot of finely tuned heuristics to get something functional
04:39:37  <SubStack>yes but the problem is that the solution space of possible programs grows at 2^n
04:39:46  <SubStack>each additional bit could describe a new program
04:40:09  <dominictarr>so, you keep n small.
04:40:29  <dominictarr>that is what I mean by precise tests
04:40:52  <dominictarr>each test should just be a few additional lines at most.
04:40:53  <SubStack>people have written programs that merely enumerate over all possible algorithms and they aren't practical at all
04:41:09  <SubStack>because to test them you run into the halting problem
04:41:14  <SubStack>but even then, testing is expensive
04:41:20  <dominictarr>timeouts
04:42:11  <SubStack>I doubt that humans are enumerating over all possible algorithms when we write computer programs
04:42:38  <dominictarr>no. we're probably applying patterns we have internalized
04:42:47  <SubStack>well
04:43:49  * ryan_stevensjoined
04:44:06  <SubStack>I suspect that humans have some innate capacity for efficiently pairing related concepts to get a desired outcome
04:44:12  <SubStack>not just humans either
04:44:26  <SubStack>and that we're using that subsystem when we write computer programs
04:44:39  <SubStack>one thing I've explored is using function composition
04:44:45  <SubStack>to pair these related concepts
04:45:07  <SubStack>and using type hints to pare down the solution space
04:45:29  <SubStack>for instance if you know that the problem you're trying to solve has output [Bits]
04:45:34  <dominictarr>that sounds good
04:45:49  <SubStack>or rather [Bit]
04:46:18  <SubStack>then you can only look at combinations that solve the output constraint
04:46:28  <dominictarr>also if you can see that one wrong solution is closer to right than another, then you can use A* like search
04:47:10  <SubStack>like ((Bit -> Bit) -> [Bit]) . (. ((Bit -> Bit) -> [Bit]))
04:47:22  <dominictarr>yup
04:47:33  <SubStack>if you have those 2 type signatures in your immediate recall
04:49:00  <SubStack>yep you can bias the type sig selection pool by doing inferences from the output
04:49:34  <SubStack>it shouldn't converge completely though because sometimes you need an algorithm that is far away to kick the system out of a local maxima
04:50:14  <dominictarr>no, but a local maxima may still be good enough.
04:50:33  <SubStack>well I imagine this system as continuously producing output
04:50:39  <dominictarr>ah
04:50:40  <dominictarr>yes.
04:51:05  <SubStack>based on whichever algorithm is producing the best output at the moment
04:52:14  <SubStack>it might even be wise to shake up the algorithm pool when the solutions start to converge too much but still isn't completely correct
04:52:19  <SubStack>cosmic ray style
04:52:55  <dominictarr>you could also have monkeys embedded that direct the hard ones.
04:53:16  <dominictarr>with their awesome wet ware pattern recognition systems
04:53:24  <SubStack>I bet brains have tons of these kind of hackneyed runtime patches
04:53:46  <SubStack>but somewhere in there is an elegant algorithm
04:54:12  <dominictarr>only elegant problems have elegant solutions.
04:54:17  <SubStack>haha maybe
04:54:23  <dominictarr>and life is full of messy problems.
04:54:46  <dominictarr>like the four-colour problem, for example.
04:54:56  <SubStack>the real question is how you turn this problem into something you can incrementally solve
04:55:38  <dominictarr>yes. this is why I say 'sufficantly precise tests'
04:56:03  <dominictarr>the user would have to have a sense of how hard it is to pass a given test.
04:56:26  <dominictarr>and just add a bit at a time to lead the code there
04:57:05  <SubStack>maybe by checking the convergence rates?
04:57:20  <SubStack>take the derivative or the second deriv
04:57:32  <SubStack>USING MATHEMATICS
04:57:32  <LOUDBOT>POOT SLAP POOT SLAP DANSK? WHAT'S THAT STAUNCH
04:57:50  <dominictarr>you would need a way to measure how close you are event though your still wrong
04:58:04  <dominictarr>you test framework needs 'warmer' and 'colder'
04:58:13  <SubStack>yeah
04:58:33  <rowbit>Hourly usage stats: [free: 5]
04:58:34  <SubStack>very analog
04:58:39  <dominictarr>maybe you could use this for searching through other design spaces
04:58:43  <dominictarr>not code.
04:59:24  <dominictarr>or stuff that is minimally like code.
04:59:30  <dominictarr>or just fsms
04:59:36  <dominictarr>FSMs
04:59:51  <dominictarr>alot of coding is just FSMs anyway.
05:00:38  <SubStack>maybe just something really silly
05:00:44  <SubStack>like how many bits in the output are the same
05:01:25  <SubStack>more bits the same === moar betters
05:01:28  <dominictarr>that will only lead you closer in particular problems
05:01:40  <SubStack>it might be good enough to prototype with
05:01:56  <SubStack>and then you'll know which programs are good for that and which aren't
05:02:14  <SubStack>and you might be able to notice something important based on that information
05:03:12  <dominictarr>I think it would need to be in the test.
05:03:43  <dominictarr>like make if it's a number sequence you use the distance
05:04:01  <SubStack>I'm still thinking along the lines of how you would bootstrap a performant algorithm writer
05:04:19  <dominictarr>each item in the actual and expected sequences.
05:05:46  <dominictarr>but if it's a different requirement the user might say I want an 8 here, but a even number is closer than an odd.
05:06:16  <SubStack>I want to write a type signature solver now
05:06:53  <dominictarr>haha. very good
05:08:08  <SubStack>and if I feel like writing something I know from past experience that I should drop everything to go and write it
05:08:14  <SubStack>or else the feeling might pass
05:09:02  <SubStack>I'll write this in javascript because it'll be way easier
05:09:11  <SubStack>I tried to write one of these in haskell and it was way too hard
05:09:28  <SubStack>that was years ago
05:09:37  <dominictarr>but how will you know the types in js? the user will have to declare them?
05:09:45  <SubStack>yes
05:10:03  <SubStack>you just give the module a toolbox of functions paired up with their type signatures
05:10:16  <dominictarr>well, that is okay.
05:10:38  <dominictarr>optional static typing
05:10:53  <SubStack>and it will output combinations of functions that compose to satisfy the desired output type
05:11:08  <dominictarr>cool!
05:11:15  <SubStack>anything else belongs in a separate module
05:13:00  <dominictarr>I'll be looking forward to see what you come up with.
05:16:05  <dominictarr>what if the type signature included not just the type, but properties that where true about the values.
05:16:27  <dominictarr>like that a number was positive, even, or that a list was in order.
05:16:31  <SubStack>invariants?
05:16:36  <dominictarr>yeah.
05:16:48  <dominictarr>i think
05:17:09  <SubStack>that would be useful information for another system to aggregate
05:17:21  <SubStack>a system that uses a biased sigsolve pool
05:17:43  <dominictarr>yeah
05:18:10  <SubStack>well it's tricky
05:18:20  <SubStack>because you'd need rules for how invariants compose
05:18:34  <dominictarr>it's another problem.
05:19:30  <SubStack>that would be wicked sweet to get algorithms from sigsolve and then to run those through an invariant system that knows how invariants compose to tell you the invariants of the entire composition
05:20:22  <dominictarr>I guess you would need to know the variants to do that.
05:22:34  <SubStack>another sweet thing would be to save every algorithm that completely matches the output back into the toolbox
05:23:00  <SubStack>then the system could recombine algorithms it's used previously to solve new problems
05:32:49  * isaacsquit (Ping timeout: 244 seconds)
05:33:42  * wiwilliaquit (Ping timeout: 248 seconds)
05:36:18  * isaacsjoined
05:55:00  <dominictarr>SubStack: yeah it's parallelizabe with memoization.
05:55:13  <dominictarr>should be massively scalable.
05:58:32  <rowbit>Hourly usage stats: [free: 16]
06:18:49  * ryan_stevensquit (Quit: Leaving.)
06:25:58  * sorensenquit (Read error: Operation timed out)
06:27:34  * sorensenjoined
06:48:03  <niftylettuce>SubStack: hey do you have Google Chat?
06:48:17  <niftylettuce>was wondering if you guys had any advice for me for making my reservations / travel / transportation plans
06:48:50  <niftylettuce>I can't fly to San Jose, even though it is closer than SFO to YC, the extra plane stops and $ aren't worth it
06:49:22  <niftylettuce>saw your FB post about biking all about, so I figured you would be perfect to ask
06:49:48  <maxogden>niftylettuce: you can get from SFO to stackhaus on public transportation
06:50:01  <maxogden>niftylettuce: and you can take the caltrain to get to YC probably. where is YC?
06:58:33  <rowbit>Hourly usage stats: [free: 17]
07:00:49  <niftylettuce>yeah right next to Caltrain
07:01:14  <niftylettuce>maxogden: 320 Pioneer Way, Mountain View, CA
07:01:32  <maxogden>yea i'd recommend caltraining
07:01:47  <maxogden>you can do the bart from oakland to SF and then get on the caltrain there
07:04:34  <niftylettuce>do you think from ~ 4PM to 8PM on a Saturday, 4 hours is enough to get from YC to SFO?
07:04:51  <niftylettuce>i dont see why it wouldnt be enough
07:04:57  <niftylettuce>but my plane would leave at 10PM
07:05:03  <niftylettuce>so i figure 1-2 hrs before is good bet
07:07:15  <SubStack>niftylettuce: consider flying into OAK
07:07:21  <SubStack>or SFO
07:08:12  <niftylettuce>flying from SCE
07:08:39  <niftylettuce>flying to OAK has at least 4 stops each way, so that might not be too cool
07:08:47  <SubStack>4 hours is plenty to get from the airport to MV
07:09:00  <niftylettuce>ah phew
07:09:06  <SubStack>just get on the caltrain at millbrae
07:09:17  <SubStack>take the bart from SFO to millbrae
07:09:37  <SubStack>then caltrain down to MV
07:09:50  <niftylettuce>and same in reverse
07:10:12  <niftylettuce>what about to Oakland? SFO bart to Oakland, then bart to Millbrae? and then caltrain to MV?
07:10:25  <SubStack>well coming back from YC you can take caltrain to millbrae then hop on BART to oakland
07:11:03  * tilgoviquit (Ping timeout: 272 seconds)
07:11:03  <niftylettuce>I'm supposed to hear back that evening after interview if I get accepted, but I have two finals so I really have to be back by Sunday (my interview is Saturday)
07:12:07  <SubStack>what do you mean "to oakland"?
07:12:12  <SubStack>where are you starting from
07:12:43  <niftylettuce>SFO
07:13:15  <niftylettuce>hmm, it would be smarter to just fly in Saturday morning and then fly back Sunday after staying a night in Oakland
07:13:36  <niftylettuce>vs. flying in Friday night, staying in Oakland, then next day going to YC from Oakland, and from YC to SFO
07:13:42  <niftylettuce>not sure what the best route/plan would be
07:14:09  * niftylettucehas never flown solo, let alone in past 4 yrs
07:19:48  <niftylettuce>ill just take I-80 and be there in 24 hrs :P http://g.co/maps/hqcb5
07:19:54  <niftylettuce>48 rather
07:23:44  * st_lukequit (Remote host closed the connection)
07:58:33  <rowbit>Hourly usage stats: [developer: 1, free: 28]
08:00:08  * isaacsquit (Remote host closed the connection)
08:00:56  * isaacsjoined
08:27:39  * dominictarrquit (Ping timeout: 245 seconds)
08:42:55  <SubStack>https://github.com/substack/sigsolve
08:43:52  <SubStack>but this algorithm only works when the types are 2-element
08:44:55  <SubStack>I'll just transform input to convert multi-element signatures into 2-element
08:58:32  <rowbit>Hourly usage stats: [free: 38]
09:58:33  <rowbit>Hourly usage stats: [free: 52]
10:58:33  <rowbit>Hourly usage stats: [free: 73]
11:56:23  * py1honquit (Ping timeout: 260 seconds)
11:56:29  * py1honjoined
11:58:33  <rowbit>Hourly usage stats: [free: 70]
12:37:55  * TheJHjoined
12:58:33  <rowbit>Hourly usage stats: [free: 65]
13:58:33  <rowbit>Hourly usage stats: [free: 59]
13:59:26  * wiwilliajoined
14:58:33  <rowbit>Hourly usage stats: [free: 44]
15:01:40  * wiwilliaquit (Ping timeout: 244 seconds)
15:05:34  * wiwilliajoined
15:18:34  * devaholicquit (Ping timeout: 246 seconds)
15:56:07  * ryan_stevensjoined
15:58:33  <rowbit>Hourly usage stats: [free: 64]
16:08:54  * isaacsquit (Read error: Connection reset by peer)
16:09:31  * isaacsjoined
16:46:51  * st_lukejoined
16:48:17  * st_lukequit (Remote host closed the connection)
16:48:43  * st_lukejoined
16:53:52  * st_lukequit (Ping timeout: 276 seconds)
16:58:33  <rowbit>Hourly usage stats: [developer: 1, free: 36]
17:27:19  * Wheltonjoined
17:28:23  * Wheltonchanged nick to Sprid
17:34:03  <isaacs>it'd be nice if there was a bit more innovation around the AST tooling for JavaScript.
17:34:23  <isaacs>like, actually try to get the AST representations to a point where a person could reasonably be expected to type out a program that way
17:34:50  <isaacs>like, a lispy language that deterministically transforms to and from JS
17:34:53  * Spridchanged nick to Whelton
17:35:13  <isaacs>so you could use it as an intermediate representation like uglifyjs does, but optimized a bit more for human consumption
17:35:25  <isaacs>then we could write macros that work on our js programs in a more clean way
17:36:12  <isaacs>which is sort of what burrito does, of course, but burrito is limited by the fact that uglify is somewhat less ergonomic than it could be
17:38:50  <Raynos>SubStack: dnode middleware is nice :)
17:39:25  <chapel>don't say middleware near mikeal :P
17:39:40  <Raynos>isaacs: Isn't there an "awesome ideas I want you guys to implement for me" outlet you can abuse?
17:39:57  <Raynos>mikeal: I like the way tacos implements middleware, it's really easy to use
17:39:57  <isaacs>Raynos: i'm abusing it right now
17:40:11  <isaacs>Raynos: SubStack is that outlet, haven't you figured this out yet? ;)
17:40:23  <Raynos>isaacs: Is this called the "glare at substack until he implements" its technique?
17:40:29  <chapel>just have to seed him with an idea
17:40:33  <isaacs>Raynos: no, no glaring. i just drop interesting ideas in his general vicinity, then he does them.
17:40:38  <chapel>and he hacks away
17:40:38  <chapel>he is like a module factory
17:40:51  <Raynos>isaacs: oh, so subtle manipulation
17:41:07  <isaacs>com.stack.sub Implements ModuleGeneratorFactory
17:42:29  <ryan_stevens>but sometimes he implements TeeShirtDesignFactory
17:58:33  <rowbit>Hourly usage stats: [developer: 1, free: 36]
18:13:15  <isaacs>ryan_stevens: TeeShirtDesign inherits from Module, so it's implied.
18:13:50  <ryan_stevens>isaacs: ohhh.. dur
18:14:04  <isaacs>ryan_stevens: via polymorphic isometric parameterization of classic hierarchical pattern matching chinamarket
18:14:29  <isaacs>LOUDBOT: search polymorphism
18:14:29  <LOUDBOT>isaacs: <a_duck:#peltkore [1]> THE ELEGANT SOLUTION IS POLYMORPHISM
18:14:33  <isaacs>LOUDBOT: search polymorphic
18:14:34  <LOUDBOT>isaacs: <apeiron:#stimutacs [1]> YOU'RE A POLYMORPHIC LOOKUP
18:14:41  <isaacs>LOUDBOT: twitlast
18:14:42  <LOUDBOT>isaacs: http://twitter.com/loudbot/status/192677408237817858 (apeiron/#stimutacs)
18:47:21  <Raynos>Does anyone have an opinion on how to trick browserify
18:47:38  <Raynos>Say I have a module that's basically an if statement. if browser require("client") else require("server")
18:47:56  <Raynos>browserify goes of and extracts the "server" token and then tries to browserify it which fails horribly
18:48:01  <SubStack>(require)()
18:48:24  <SubStack>or you can put a "browserify" field in your package.json
18:48:38  <SubStack>which is a variant of "main" that browserify will use instead
18:51:22  <Raynos>I see
18:51:28  <Raynos>(require)(string) really tricks it?
18:51:36  <Raynos>what is the point of detective if it falls for that? :P
18:52:03  * Wheltonpart
18:52:27  <Raynos>(require)(str) didn't trick it :(
18:54:53  <Raynos>>_<
18:54:59  <Raynos>I see what the problem is
18:58:32  <rowbit>Hourly usage stats: [developer: 2, free: 50]
19:58:33  <rowbit>Daily usage stats: [developer: 9, free: 863]
19:58:33  <rowbit>Hourly usage stats: [free: 46]
20:37:24  * tilgovijoined
20:46:23  * jeffbcrossjoined
20:46:37  * jeffbcrosspart
20:54:21  * tilgoviquit (Quit: No Ping reply in 180 seconds.)
20:54:51  * tilgovijoined
20:58:32  <rowbit>Hourly usage stats: [free: 40]
21:08:56  * tilgoviquit (Ping timeout: 245 seconds)
21:17:59  <niftylettuce>got my plane tickets
21:18:07  <niftylettuce>grab life by the balls people
21:27:59  <SubStack>hooray
21:34:22  <SubStack>just realized !ud in ddg goes to urban dictionary
21:34:49  <SubStack>NOW I SHALL UNDERSTAND THE LINGOS OF THE KIDS THESE DAYS BECAUSE I HAVE AN URBAN DICTIONARY
21:34:49  <LOUDBOT>IF DEITIES ARE ARTISTS THEN WHAT WOULD SHIVA PAINT
21:35:41  * devaholicjoined
21:36:45  * tilgovijoined
21:51:38  * Wheltonjoined
21:58:32  <rowbit>Hourly usage stats: [free: 39]
22:00:17  * devaholicquit (Ping timeout: 245 seconds)
22:02:09  * devaholicjoined
22:07:16  * TheJHquit (Ping timeout: 264 seconds)
22:16:20  * Wheltonquit (Quit: Whelton)
22:58:33  <rowbit>Hourly usage stats: [free: 19]
23:17:19  * isaacsquit (Remote host closed the connection)
23:22:12  * ryan_stevensquit (Quit: Leaving.)
23:41:26  * saijanai_quit (*.net *.split)
23:41:26  * jesusabdullahquit (*.net *.split)
23:41:26  * doolsquit (*.net *.split)
23:42:09  * jesusabdullahjoined
23:51:24  * ryan_stevensjoined
23:52:24  * saijanai_joined
23:52:24  * doolsjoined
23:58:33  <rowbit>Hourly usage stats: [free: 15]