5 ms·

At a certain scale, it's often a lot easier to build one system that solves all the problems. Building a building: hard problem. Building 1/3 of a building: i

by yarvin9 11y ago

At a certain scale, it's often a lot easier to build one system that solves all the problems. Building a building: hard problem. Building 1/3 of a building: impossible problem. Building a cow: hard problem. Building 1/3 of a cow: impossible problem.

Detrus 11y ago
Well, some types of buildings are designed to be modular. Cows are not. I'm also in favor of a single system that solves a bunch of problems than a hodgepodge nightmare. That was the vision behind NLS, the Mother of All Demos, SmallTalk, Plan9 etc. And Doug Engelbart can be found favoring the easy to master but complex at first glance approach https://www.youtube.com/watch?v=VeSgaJt27PM https://www.youtube.com/watch?v=VeSgaJt27PM instead of the easy to get started approach of Mac GUIs that won out. The problem arises when the system makes too many weird decisions and people fork it to make their own all encompassing systems. Then it takes forever for crippled versions of these system to be adopted. It doesn't help when even the niche audience is divided. Things that can be disagreed on should be minimized. So there is no technical need to throw the complex at first glance syntax at new users these days. You could convert it to a more verbose syntax and back again. Terse syntax looks clean and easy to scan when you use it daily. But what if you don't? Then it's not self documenting, you have to look up commands to read code. If I don't use command line for a few months, I remember the basics like mkdir, ls, cd but I forget the nuances like ls -a and the billion other options. So it becomes a chore of looking things up constantly. Could be fixed with natural language autocomplete for writing code, but not reading. If you considered such use cases, you wouldn't be so sure about the terse syntax. So many made up words are also asking too much. They'll certainly be worth learning if the system is proven. Haskell has it's own way of doing things, does a lot of things well, but seems to make many things difficult in practice. So it remains a niche that very few learn beyond the surface curiosities. Same for APL, J and K. And I wrote most of this before seeing https://news.ycombinator.com/item?id=10280348 https://news.ycombinator.com/item?id=10280348
KingMob 11y ago
Without addressing the merits of Urbit, these examples aren't valid. A third of a building is just a building in progress (foundations laid, i-beams installed, etc.) A third of a cow is a calf. It might be the case that you will get synergistic effects and/or Urbit's vision isn't possible without solving multiple problems. But it could equally be you've bitten off more than you could chew by choosing to work on multiple orthogonal problems.
- idlewords 11y ago
  A third of a cow is dinner!
- galaxyLogic 11y ago
  Thanks. Dividera et Impera. This is the whole idea behind modularity. Solve the network-abstraction problem the best way you can. Then solve the programming language problem the best you can. Do we need a "network programming language"? Maybe, but general purpose programming languages are better for other things, and they too should be able to talk to the network "layer". I probably missed a lot on the article, it was so long to read. Of course if you have new concepts they need a name of their own. But that only applies if all the new concepts really are new. If they are the same old concepts, use the same old commonly understood name. If they are somewhat different, use a derived name, like "Big Potatoes". They are LIKE potatoes, but they are really big. If they are totally different, try to invent a name that EXPLAINS THEM BY COMBINING the names of previously existing concepts. How many people program in "BrainFuck" and get paid for it? There must be a reason that there are not so many professional brainfuck programmers around. Nevertheless I applaud this project for thinking outside the box, if that is possible they have done it.
tptacek 11y ago
I mean, this is pithy and all, but it obviously doesn't rebut my point. You could apply the same logic to any disparate collection of engineering problems.
- yarvin9 11y ago
  No, you're right, it's a highbrow dismissal. Let me be a little more detailed. Once you've built a system that's both a protocol and an OS, you realize that putting an abstraction barrier between them is like building a cow by building two halves of the cow, then sewing them together. It's incredibly hard and the resulting cow doesn't work very well. Take a problem like identity. Is this an OS problem, or a protocol problem? Earlier I mentioned validation of message / content types. Is this an OS problem, or a protocol problem? Is the spinal column part of the cow-frontend, or the cow-backend? These are just the most obvious examples. For instance, the standard way of building protocols assumes that message processing isn't transactional, and the OS is a dual-level store that loses its mind all the time. If your OS is a single-level store, you can essentially use persistent sessions. Which means you can get exactly-once messaging. Which is a very desirable feature that's impossible to achieve if you assume that the endpoints can lose their minds. So the appropriate comparison is: build the front-end of a cow, and stitch it to the back end of an alligator, creating the mighty alligow; or, build a whole cow. Granted, Urbit isn't perfect and I'd hardly call it done, but the whole stack (counting apps!) is only 25K lines of code. So the "whole cow" doesn't seem appalling. The alligow -- I wouldn't even try.
  - tptacek 11y ago
    The notion that the OS and the network are essentially the same thing, a series of procedure calls somehow knitted together either with a stack in memory or as a series of serialized frames on a network, strikes me as a very 1980s way of framing computer science. I feel like the last 20 years of network software development have been a repudiation of that idea. So yeah, I find it frustrating that Urbit insists that an overlay network is "half the cow", and that to have a "whole cow", we must also adopt an excruciatingly idiosyncratic bespoke programming language. Mostly, for me, this is coming from a place of deep respect for the concept and potential of overlay networks, and of frustration with designs that seem to sabotage that potential in order to make philosophical/political statements. (That's my only attachment to Urbit as a thing worth discussing; by way of bona fides: https://hn.algolia.com/?query=author:tptacek%20overlay%20network&sort=byPopularity&prefix=false&page=0&dateRange=all&type=comment https://hn.algolia.com/?query=author:tptacek%20overlay%20net...)
networked 11y ago
>At a certain scale, it's often a lot easier to build one system that solves all the problems. I have been wondering, are you familiar with Project Xanadu and Ted Nelson's work in general? Project Xanadu took a "whole cow" approach to building a network centered around publishing documents and linking between them. The stated goals for Urbit and Xanadu seem to overlap [1] enough that Xanadu would be easier to implement on top of Urbit than on top of anything else. It could then be Urbit's superior alternative to the World Wide Web for publishing hypertext documents. Last year I emailed Nelson asking whether he knew about Urbit (secretly hoping he might already be working with or for you) but he replied he didn't. [1] https://en.wikipedia.org/wiki/Project_Xanadu#Original_17_rules https://en.wikipedia.org/wiki/Project_Xanadu#Original_17_rul...

by yarvin9 11y ago

Detrus 11y ago

Well, some types of buildings are designed to be modular. Cows are not. I'm also in favor of a single system that solves a bunch of problems than a hodgepodge nightmare. That was the vision behind NLS, the Mother of All Demos, SmallTalk, Plan9 etc. And Doug Engelbart can be found favoring the easy to master but complex at first glance approach https://www.youtube.com/watch?v=VeSgaJt27PM https://www.youtube.com/watch?v=VeSgaJt27PM instead of the easy to get started approach of Mac GUIs that won out. The problem arises when the system makes too many weird decisions and people fork it to make their own all encompassing systems. Then it takes forever for crippled versions of these system to be adopted. It doesn't help when even the niche audience is divided. Things that can be disagreed on should be minimized. So there is no technical need to throw the complex at first glance syntax at new users these days. You could convert it to a more verbose syntax and back again. Terse syntax looks clean and easy to scan when you use it daily. But what if you don't? Then it's not self documenting, you have to look up commands to read code. If I don't use command line for a few months, I remember the basics like mkdir, ls, cd but I forget the nuances like ls -a and the billion other options. So it becomes a chore of looking things up constantly. Could be fixed with natural language autocomplete for writing code, but not reading. If you considered such use cases, you wouldn't be so sure about the terse syntax. So many made up words are also asking too much. They'll certainly be worth learning if the system is proven. Haskell has it's own way of doing things, does a lot of things well, but seems to make many things difficult in practice. So it remains a niche that very few learn beyond the surface curiosities. Same for APL, J and K. And I wrote most of this before seeing https://news.ycombinator.com/item?id=10280348 https://news.ycombinator.com/item?id=10280348

KingMob 11y ago

Without addressing the merits of Urbit, these examples aren't valid. A third of a building is just a building in progress (foundations laid, i-beams installed, etc.) A third of a cow is a calf. It might be the case that you will get synergistic effects and/or Urbit's vision isn't possible without solving multiple problems. But it could equally be you've bitten off more than you could chew by choosing to work on multiple orthogonal problems.

idlewords 11y ago
A third of a cow is dinner!
galaxyLogic 11y ago
Thanks. Dividera et Impera. This is the whole idea behind modularity. Solve the network-abstraction problem the best way you can. Then solve the programming language problem the best you can. Do we need a "network programming language"? Maybe, but general purpose programming languages are better for other things, and they too should be able to talk to the network "layer". I probably missed a lot on the article, it was so long to read. Of course if you have new concepts they need a name of their own. But that only applies if all the new concepts really are new. If they are the same old concepts, use the same old commonly understood name. If they are somewhat different, use a derived name, like "Big Potatoes". They are LIKE potatoes, but they are really big. If they are totally different, try to invent a name that EXPLAINS THEM BY COMBINING the names of previously existing concepts. How many people program in "BrainFuck" and get paid for it? There must be a reason that there are not so many professional brainfuck programmers around. Nevertheless I applaud this project for thinking outside the box, if that is possible they have done it.

tptacek 11y ago

I mean, this is pithy and all, but it obviously doesn't rebut my point. You could apply the same logic to any disparate collection of engineering problems.

yarvin9 11y ago
No, you're right, it's a highbrow dismissal. Let me be a little more detailed. Once you've built a system that's both a protocol and an OS, you realize that putting an abstraction barrier between them is like building a cow by building two halves of the cow, then sewing them together. It's incredibly hard and the resulting cow doesn't work very well. Take a problem like identity. Is this an OS problem, or a protocol problem? Earlier I mentioned validation of message / content types. Is this an OS problem, or a protocol problem? Is the spinal column part of the cow-frontend, or the cow-backend? These are just the most obvious examples. For instance, the standard way of building protocols assumes that message processing isn't transactional, and the OS is a dual-level store that loses its mind all the time. If your OS is a single-level store, you can essentially use persistent sessions. Which means you can get exactly-once messaging. Which is a very desirable feature that's impossible to achieve if you assume that the endpoints can lose their minds. So the appropriate comparison is: build the front-end of a cow, and stitch it to the back end of an alligator, creating the mighty alligow; or, build a whole cow. Granted, Urbit isn't perfect and I'd hardly call it done, but the whole stack (counting apps!) is only 25K lines of code. So the "whole cow" doesn't seem appalling. The alligow -- I wouldn't even try.
- tptacek 11y ago
  The notion that the OS and the network are essentially the same thing, a series of procedure calls somehow knitted together either with a stack in memory or as a series of serialized frames on a network, strikes me as a very 1980s way of framing computer science. I feel like the last 20 years of network software development have been a repudiation of that idea. So yeah, I find it frustrating that Urbit insists that an overlay network is "half the cow", and that to have a "whole cow", we must also adopt an excruciatingly idiosyncratic bespoke programming language. Mostly, for me, this is coming from a place of deep respect for the concept and potential of overlay networks, and of frustration with designs that seem to sabotage that potential in order to make philosophical/political statements. (That's my only attachment to Urbit as a thing worth discussing; by way of bona fides: https://hn.algolia.com/?query=author:tptacek%20overlay%20network&sort=byPopularity&prefix=false&page=0&dateRange=all&type=comment https://hn.algolia.com/?query=author:tptacek%20overlay%20net...)

networked 11y ago

>At a certain scale, it's often a lot easier to build one system that solves all the problems. I have been wondering, are you familiar with Project Xanadu and Ted Nelson's work in general? Project Xanadu took a "whole cow" approach to building a network centered around publishing documents and linking between them. The stated goals for Urbit and Xanadu seem to overlap [1] enough that Xanadu would be easier to implement on top of Urbit than on top of anything else. It could then be Urbit's superior alternative to the World Wide Web for publishing hypertext documents. Last year I emailed Nelson asking whether he knew about Urbit (secretly hoping he might already be working with or for you) but he replied he didn't. [1] https://en.wikipedia.org/wiki/Project_Xanadu#Original_17_rules https://en.wikipedia.org/wiki/Project_Xanadu#Original_17_rul...