|
| 1 | +--- |
| 2 | +title: JE 5/25/19 |
| 3 | +--- |
| 4 | + |
| 5 | +# JE 5/25/19 |
| 6 | + |
| 7 | +_Friday May 24, 2019_ |
| 8 | + |
| 9 | +I realized I haven't been spending enough time on research so this week I made sure to spend 20 hours on it. Truly half time. Very exciting. |
| 10 | + |
| 11 | +As for my immutable world, both IPFS and Unison have interesting answers. IPFS has one real and one cheat. The real is that a name is just a public/private key pair and pushing to it is publishing something signed with the public key. The fake is just using DNS. |
| 12 | + |
| 13 | +Unison doesn't focus on time-varying values. Everything is immutable. If you want to edit a thing, you can and it will walk you through the possibilities of updating some dependencies or not, and correcting for the changed type as well. There's no notion of libraries that can change over time. That would be built on top. http://unisonweb.org/2016-09-17/editing.html |
| 14 | + |
| 15 | +I think the IPFS way works for me. |
| 16 | + |
| 17 | +Thinking about IoT uses to be fully expressive with FRP. Such as put the image from my camera on this portion of my screen. Also haven't figured out how to do social applications with hard disk -- where *is* the data? Output devices are a bit tricky. Input devices are more straightforward. Not sure how to model the connection to the device. Nor powering the device. |
| 18 | + |
| 19 | +https://doc.rust-lang.org/stable/cargo/guide/index.html |
| 20 | + |
| 21 | +urbit - an operating function [https://urbit.org/primer/](https://urbit.org/primer/) |
| 22 | + |
| 23 | +* JE: all programming languages assume start and stop, not always running |
| 24 | +* JE: there are people that criticize the Turing Machine because of this. It's very philosophical. Hypercomputation |
| 25 | +* JE: Dan Briklen's famous quote: an OS deals with a whole number of issues outside the PL. There shouldn't be one. Smalltalk is an OS. Same with LISP machines. |
| 26 | +* Sun Microsystem: "The network is the computer" |
| 27 | +* JE: the devices that have output and also inputs (like storage) is really hard |
| 28 | +* JE: trying to make sense of an OS in FRP terms |
| 29 | +* JE: stream-based IO had a magic |
| 30 | +* JE: these are sometimes called non-functional aspects of computation |
| 31 | +* JE: the functional stream-based things was abandoned in favor of monads, now being abandoned in favor of algebraic effects |
| 32 | +* Steve: problem: I want to express my wishes over my machines, orchestrate them. smart home automation. |
| 33 | +* JE: I am concerned that if you focus on stateless stream you miss a lot of hard problems. Statefulness is essential in so much that we do. So I want to see you build your own Twitter. Or a shopping list for you and your girlfriend. |
| 34 | +* JE: hooking up streams is just boxes and wires. not a new invention. |
| 35 | +* JE: state is a central problem. kills many attempts to functionalize things |
| 36 | +* JE: need to be able to change the program on the fly on existing data (his "schema change" problem). Old LISP & Smalltalk systems didn't have principled approaches to this. |
| 37 | +* JE: so you want to think of the OS as functions or FRP streams or something. |
| 38 | +* JE: that is a problem, modeling the whole FRP, instead of just assuming we have a runner that inputs the mouse and time and outputs to the screen. we need to model the entire environment. FRP without genies or runners. |
| 39 | +* JE: how would you know if you solved this? what is the correctness criteria? |
| 40 | + * Steve: it's just if I like it, not a rubric |
| 41 | + * JE: try putting it into words, even if it's not objective. I know it when I see it doesn't give you much guidance. another thing is use-cases, challenge problems |
| 42 | + * JE: another way forward would be to criticize current approaches |
| 43 | + * JE: LabView is signal processing. how does this fail in your mind? it's dataflow but it has stateful stuff as well |
| 44 | +* Steve: ah I see now that I'm thinking very much about dataflow (facebook origami: inputs and outputs), unlike how Conal thinks of things |
| 45 | + * JE: dataflow things are mostly first order. they also have a casuality thing so no backwards in time |
| 46 | +* Steve: in dataflow systems, wires are instantaneous, but TODO |
| 47 | +* Steve: some next steps: |
| 48 | + * pseudo haskell |
| 49 | + * chat with Paul |
| 50 | +* JE: if I can't make progress in articularing problem, then loop around onto other things and come back when things are clearer |
| 51 | +* Steve: can I start an OS company to compete with all the real OS companies? |
| 52 | +* JE: there are so many ways to take ideas so don't worry about this now, such as wefounder (crowdfunding with equity) or github's new equity thing |
| 53 | + |
| 54 | +**consider helping REBLS with publicity.** I'm leaning no here but find myself reluctant to fully say no given how little time it seems. I'm going to tell JE I want to say no, and double check with him one last time. |
| 55 | + |
| 56 | +* JE: maybe you should think more about social stuff |
| 57 | +* JE: Jonathan Blow is following up from his rant-y talk and trying to organize a conference about simplifying software. maybe you could help him organize this. TODO watch the talk and see what he's saying on social media |
| 58 | +* JE: don't get upset at yourself if you don't have as much time or progress for research traveling next couple of months. |
| 59 | +* JE: try and refine the OS thing is a good next step: |
| 60 | + * criteria for success |
| 61 | + * sample problems |
| 62 | + * criticizing current solutions |
| 63 | + |
| 64 | +* JE: success would be good. downsize the problem to something I can do in 3 months |
| 65 | + |
| 66 | +* For next Friday quick meeting: OS next steps or smaller problem |
0 commit comments