3 ms·

Main Plunder dev here, wasn't expecting to see this here. This document was written by an Urbit dev, and the Urbit community is the target audience. The conve

Main Plunder dev here, wasn't expecting to see this here. This document was written by an Urbit dev, and the Urbit community is the target audience. The conversation here seems to be mostly shitting on Urbit with the usual HN critiques. However, Plunder is only tangentially related to Urbit. It's the same paradigm, but totally different otherwise. Heavy Haskell influence. The project is still mostly underground, but I'm happy to answer any questions.

Nursie 3y ago
I read your intro to PLAN. It's much easier to understand than anything I've read on this sort of topic before. I can at least come out of it understanding what the aims are and what it might provide. It's interesting. Not something I think will affect my day to day life, but in a thought-experiment, LISP-y sort of way I can see why a certain kind of coder might find such a system intriguing. I imagine such a coder is probably into language design, lambda calculus, functional purity and formal verification rather than being on the 'just get things done' end of the spectrum. I also don't think I can see such a design ever doing anything very quickly, as every operation is necessarily committed to disk. I guess that's where Jets come in... It's amusing to contrast this with the general mood in programming where we strive to make programs ephemeral so that we don't care what's in memory, things die often and we just re-start them when we feel like it, allowing them to rebuild their internal state.
- sol_plunder 3y ago
  The main use-case is for building peer-to-peer systems with small eng resources. The win is basically that the entire stack gets much less complex. Network, database, and business logic all operate within the same model. For example, once the system is finished, building a full p2p chat should be possible in a couple hundred LOC. The goal is somewhat political, to enable people to build their own social software, instead of depending on finance for everything. > I also don't think I can see such a design ever doing anything very quickly, as every operation is necessarily committed to disk. There is overhead to be sure, but it's nowhere near as bad as it sounds. In practice, we don't need to fsync every input. Each syscall chooses if it should wait for a sync before running effect. Sync only blocks that effect, everything else continues to run. For example most REPL IO doesn't need to wait for a sync, but a network transaction does.
  - Nursie 3y ago
    I’m not seeing that simplicity or low-engineering overhead from reading about PLAN, personally, I’m seeing a computer scientist’s wet dream about composability and resilience, but not anything that would promote rapid development or reduced costs. In fact I think the opposite is true - this is such a reinvention that everything is likely to take subject matter experts and a lot of time. P2P chat doesn’t seem like a very lofty goal at this point. I’m sure there’s a lot more to your platform than PLAN, providing all sorts of facilities, but at that point you’ve kinda scuppered the “execute anywhere, forever” aspect of your model IMHO, because it relies on quite a complex VM to provide the simple coding environment. Best of luck to you, but I’m still thinking “nerd trap” rather than “revolutionary tech”.
    - sol_plunder 3y ago
      [dead]
jitl 3y ago
Why is it called Plunder?
- sol_plunder 3y ago
  Think of it as being a Scheme implementation: Racket, Stalin, Larceny, Plunder.
  - jitl 3y ago
    I think presenting Plunder as a "scheme lisp machine, with persisted application state" would be great for branding on HN :)
    - sol_plunder 3y ago
      That sounds right! I'll keep that in mind. "A lisp machine with fully automatic persistence. No database or filesystem needed" is actually a fairly accurate description.

Nursie 3y ago

I read your intro to PLAN. It's much easier to understand than anything I've read on this sort of topic before. I can at least come out of it understanding what the aims are and what it might provide. It's interesting. Not something I think will affect my day to day life, but in a thought-experiment, LISP-y sort of way I can see why a certain kind of coder might find such a system intriguing. I imagine such a coder is probably into language design, lambda calculus, functional purity and formal verification rather than being on the 'just get things done' end of the spectrum. I also don't think I can see such a design ever doing anything very quickly, as every operation is necessarily committed to disk. I guess that's where Jets come in... It's amusing to contrast this with the general mood in programming where we strive to make programs ephemeral so that we don't care what's in memory, things die often and we just re-start them when we feel like it, allowing them to rebuild their internal state.

sol_plunder 3y ago
The main use-case is for building peer-to-peer systems with small eng resources. The win is basically that the entire stack gets much less complex. Network, database, and business logic all operate within the same model. For example, once the system is finished, building a full p2p chat should be possible in a couple hundred LOC. The goal is somewhat political, to enable people to build their own social software, instead of depending on finance for everything. > I also don't think I can see such a design ever doing anything very quickly, as every operation is necessarily committed to disk. There is overhead to be sure, but it's nowhere near as bad as it sounds. In practice, we don't need to fsync every input. Each syscall chooses if it should wait for a sync before running effect. Sync only blocks that effect, everything else continues to run. For example most REPL IO doesn't need to wait for a sync, but a network transaction does.
- Nursie 3y ago
  I’m not seeing that simplicity or low-engineering overhead from reading about PLAN, personally, I’m seeing a computer scientist’s wet dream about composability and resilience, but not anything that would promote rapid development or reduced costs. In fact I think the opposite is true - this is such a reinvention that everything is likely to take subject matter experts and a lot of time. P2P chat doesn’t seem like a very lofty goal at this point. I’m sure there’s a lot more to your platform than PLAN, providing all sorts of facilities, but at that point you’ve kinda scuppered the “execute anywhere, forever” aspect of your model IMHO, because it relies on quite a complex VM to provide the simple coding environment. Best of luck to you, but I’m still thinking “nerd trap” rather than “revolutionary tech”.
  - sol_plunder 3y ago
    [dead]

jitl 3y ago

Why is it called Plunder?

sol_plunder 3y ago
Think of it as being a Scheme implementation: Racket, Stalin, Larceny, Plunder.
- jitl 3y ago
  I think presenting Plunder as a "scheme lisp machine, with persisted application state" would be great for branding on HN :)
  - sol_plunder 3y ago
    That sounds right! I'll keep that in mind. "A lisp machine with fully automatic persistence. No database or filesystem needed" is actually a fairly accurate description.