You didn't understand the point, apparently. Countries that were nearly 100% racially homogeneous when they banned drugs couldn't have been doing it because of racism.
I am currently facing the grim possibility of a patent with my name on it for a system that's basically a poor imitation of decades-old technology. (But it works great with our other poor in-house imitations of decades-old technology!)
Yahoo's "non" fire sale is a good counterpart to the devil on my shoulder trying to rationalize away my participation. My job is actually pretty great otherwise (especially for the town I live in), so I'm stressed as hell at the prospect of quitting over this. I keep thinking of the Milgram experiment, and how confident I was when I heard about it that I wouldn't have been part of the majority that continued shocking a human being to the point of apparent death. Software patents are an abstract evil by comparison, but now that there's a part of me saying "yeah it seems bad, but it probably won't result in any real harm", I can somewhat empathize with that majority.
I don't really have a point to make, this just seemed like a reasonable place to vent my shame and frustration.
I'm not sure where you're getting this. The system is explicitly designed such that the author can not ultimately shape the network into whatever he wants. The only real control stars and galaxies have over the rest of the userbase is that if you want to send a packet to someone who you don't already have a direct connection to, you need at least one star willing to route your traffic. The ownership of these pieces of network infrastructure is intentionally fragmented to prevent the kind of control you're talking about.
What you're describing sounds more like the web as it currently exists under the benevolent rule of King Verisign.
How so? Sharing arbitrary objects via memory requires some form of coordinated memory management. So you still need a process-wide GC, meaning you're probably stuck with that 30% hit from thread-safe refcounting.
And all the other locking issues are still in play. How would you share a list with another interpreter such that they don't both have access to the same list items? Any solution that looks like a deep copy isn't going to be much better than just serializing across a process boundary.
Right now multi-processing use a very expensive serialization to send to one worker to another. Shared memory is much cheaper.
Even if you didn't have the GIL, you would still need locks with threads to manipulate any mutable datastructure. The usual concurreny safety advice always apply.
Well, if you define "comfortable tolerating his garbage" as "contributes to Urbit despite it being Yarvin's project", then tautological assertion is tautological.
There is certainly some self-selection for people who don't throw tech babies out with political bathwater. I count myself as one such person. I mean, I continued using Javascript and Firefox even after hearing about Brendan Eich's political contribution! Feel free to draw incorrect inferences regarding my opinion of gay marriage.
I have also toyed around with Urbit, and have (in a sense) made minor contributions. Feel free to draw incorrect inferences regarding my opinion of Yarvin's political writing.
It's not about your beliefs or what people infer about them. In fact it's not about you at all- it's about the other potential contributors and users that Yarvin is alienating, despite all the claims in this thread that his views don't impact the project.
I mean, I guess you're technically correct: If nothing else, the impact of his views on the project is that it results in the exclusion of people who choose to exclude themselves from projects created by "the wrong people".
But of course that's trivially true of all projects, so why do you think it's such a problem in this particular case? If you answer "because his views are really bad" while acknowledging that they otherwise have no direct bearing on the technology, you're basically saying "because he's really unpopular".
I have no love of Yarvin's politics, but that sort of cure is worse than the disease.
Where we seem to differ is in the importance of those people who avoid Yarvin (or Torvalds, or other more or less abrasive open source contributors), as well as the reasons they avoid him. It's more than merely ideological for many people, it's personal.
I don't acknowledge that his views have no direct bearing on the technology, either, and that's tied up in my first point. We design things for ourselves, for the most part, so by excluding (perhaps inadvertently) people with different perspectives on life, we lose out on valuable input.
Thanks for the clarification. I'm certainly not claiming that people who avoid the project are somehow "less important" as a result of their decision. And I wouldn't doubt that it's personal for them - "mere ideology" also seems like a pretty personal thing!
I think we agree that Urbit would benefit from a larger, more diverse user/contributor base. What wouldn't? We're just ascribing agency in different places. I view the claim that Yarvin is excluding people as a sort of rhetorical sleight of hand. What he's actually done is 1) publish some really unpopular opinions, and 2) build Urbit. It is entirely possible to evaluate 2 on its own merits[1]. So I'm disappointed to see so many people write it off for other IMO less relevant reasons.
It reminds me a bit of a "Christian-friendly" Linux distro I once saw that omitted software written by known homosexuals. Would you also claim that the gay programmers were (perhaps inadvertently) excluding a subset of Christians? I suspect most people would agree in this case that agents of exclusion are the ones actually performing the exclusive act, rather than ones who happened to be "the wrong people" from another group's point of view.
[1]: This is true even in the presence of a strong political influence on the technology. I honestly don't see much of a connection between Urbit and Moldbug's politics, but then the latter never made much sense to me, so maybe I'm missing something. If there are politically objectionable aspects to the software, then by all means object! But plain old guilt by association is a weak argument in any context, doubly so in a technical one.
Yes, in a hypothetical platonic code-only way you can separate Yarvin from his work to some degree. But you're underestimating the impact of the word "personal" here- some people avoid communities like this not as a boycott, but for their personal safety or emotional well-being. That's the point where they go from the excluder to the one being excluded.
Speaking as someone who's been following the project for a few years and once actually bothered to learn Hoon, your first paragraph is probably the best criticism of Urbit I've seen. I do think there is an interesting system buried under all the obfuscation, but the uncritical groupthink within its user base is obnoxious. I kind of doubt "produce a vanguard of true believers" is a primary goal of the project, but Yarvin doesn't really seem to discourage that behavior either.
That said, the old "it's just typical Moldbug" trope isn't much better than the propaganda his followers spout, and the rest is pretty weak too. AFAIK, the Urbit term for "file" is "file". I don't know which funny weird name you're thinking of for "network endpoint", as that's not really a separate concept in the system. Hoon's cores (which I assume you're at least passingly familiar with) are pretty distinct from closures in any language I know... I mean, do you also complain that Java uses the word "object"? (Forgive me if I omit the part where I ascribe sinister motives to the creators of Java due to their choice of vocabulary.)
As for "implementations of well-known computer science concepts", cue Rich Hickey[1]:
> It's interesting, because Clojure provides almost nothing you can’t find somewhere else. But I do think it occupies an otherwise empty spot in the multidimensional space of language features and capabilities.
In other words, even if your claim is true, it describes almost every project in computing in the last 15 years. We might as well say "oh it's just event sourcing" and call it a day.
Funny you should mention Clojure -- a language that I found to not bestow any appreciable performance, abstraction, or usability advantage compared to a halfway decent Scheme-on-Java such as Kawa, yet still be different enough to be annoying.
If you like Clojure, don't let me stop you. But I've shipped servlets written in Scheme that did millions of dollars in business... forgive me if I personally am a bit slow to accept that Rich Hickey has brought us fire from the gods.
In other words, even if your claim is true, it describes almost every project in computing in the last 15 years.
Now you see why when tickets go on sale for the next language, framework, or OS hypetrain, I'm quite reluctant to buy.
That said, the old "it's just typical Moldbug" trope isn't much better than the propaganda his followers spout, and the rest is pretty weak too.
Urbit is almost never presented as "here's an interesting pure-functional VM and OS abstraction layer I've been working on, I think its advantages are this-and-such" but Grand Pronouncements like "The Internet Has Failed. We are writing its successor. Join us. It is your destiny." The rationale is that since data silos are more common and accessible than distributed systems and ISPs are dickheads on the modern internet the internet itself is architecturally unsound. But data silos and dickhead ISPs are much more a social problem than a technical one, and I never heard technical reasoning for why the internet is broken from the Urbit folks.
It's always "Google, Facebook, AOL, Comcast, therefore Unix and the internet are broken." But there's no chain of reasoning in the middle. It's a rhetorical cup-and-ball game.
And when I challenge the Urbit folks on this and tell them that I see no benefit to Urbit that I can't get from other more battle-tested systems, and that Urbit is different enough to be annoying without being advantageous, I get one of a few stock responses:
"That was fine for 1975. We're trying to build a system for 2015."
It is 2015 (now 2016). You still haven't specified in any detail how the system I run every day isn't up to the task.
"We want to make administering your server as easy as administering your smartphone."
Smartphones are administered largely from afar, by actors whose interests mainly do not coincide with my own. So I don't think that's a goal you can really reach without severely compromising your vision.
"In practice, Hoon is really easy and pleasant to use."
So is Scheme. So is Haskell if you want to go full functional. So is C once you adopt certain simple practices. How, exactly, is Hoon easier and more pleasant than these?
"Uhhh, yeah, we're working on making the documentation clearer and the names less weird..."
Good. I might check again when that work is completed.
I've encountered arguments of this type (Grand Pronouncements of the doom of the status quo, stock phrases as to why our system/product is better with a dearth of reasoning) before. It never, ever comes from a good place.
And I totally get the desire to play at being Alan Kay. But doing that successfully requires Alan Kay levels of insight into how computers and brains work deep down, which Moldbug hasn't convinced me he has.
I don't think Hoon's type system actually has a typeclass analogue. As far as I could tell, what it has is something like generics, but in a world where everything is ultimately a noun. IIRC, a previous iteration of the docs explained that "wet gates" (generic functions) are actually required to compile down to the same Nock when "instantiated" at a particular argument, modulo dead code elimination. Didn't look much like ad-hoc polymorphism to me.
A good example is Hoon's maps[1]. They're parameterized on type, but I'm pretty sure those types can't affect the runtime behavior by, say, specifying their own hash or comparison function. Instead, the map implementation[2] hardwires a couple of specific comparison functions[3] that effectively toss the type information and work in terms of the raw underlying nouns.
It is kind of weird that every type carves out a subset of nouns, even function types (or function "molds" or "spans" or whatever... I'll stop calling them types when the Urbit people stop calling it a type system). Hoon's C-flavor really shows when it makes the likes of strlen((char*)strlen) expressible in a purely functional way.
