zonotope

> Good point! I guess it's not different to the equator on the surface of a sphere... so yes, a straight line "encloses" half of the plane "inside" it, so it has a hole.

My topology is rusty, but I do not think that a line in the plane is equivalent to an equator of a sphere because a plane is not equivalent to a sphere in a topological sense, and neither is a line equivalent to a circle. There is no homeomorphism (structure preserving bijective function) between either pairs of spaces.

There is a standard way to augment the plane/line to make it equivalent to a sphere/circle called the "1-point compactification"[1], but since it requires adding an extra point "at infinity", the augmented space is not the same as the original.

So no, a straight line doesn't have a "hole" in the topological sense. The 1-point compactification of it does though.

1: https://en.wikipedia.org/wiki/Alexandroff_extension

Change one law, or negotiate with hundreds of thousands of employers, school boards, day care centers, among other things, simultaneously, in the hopes that they all come to the same decision. Seems easier to me.

> I prefer functional programming, and have a background in functional programming, but I still primarily work with Java... In my opinion, Java as a language is gross and unlovable, but the runtime, the development tooling, and selection of libraries and other integrations is about as good as it gets.

It sounds like Clojure is perfect for you then. You have all the upsides of Java you mention here with Clojure because it's hosted on the JVM (among other platforms). You can use Java libraries and SDKs seamlessly from Clojure, but the language itself was designed specifically for a functional style from the beginning.

How will these remaining good websites make enough money to sustain themselves?

Sure. First, a little background. The Tupelo distributed ledger manages repo identities and permissions, while Sia persists the actual git objects.

Tupelo validates transactions against individual ChainTrees, and you can think of a ChainTree as an independent ledger (or blockchain) that represents the state of one independent real world (or digital) object. In this case, that object is a git repository.

Tupelo only allows the "owner" of a ChainTree to make modifications to that ChainTree (such as updating the current HEAD), and ownership is determined by control of a private key.

Each ChainTree has a unique DID (decentralized identifier) that is uniquely determined by the key that first created it, and the controller of that key is the initial owner. Tupelo also has a transaction type that allows the current owner to transfer a ChainTree to a different key maintained by the new owner, but its DID stays the same after that transfer.

Tupelo uses a strategy similar to the WarpWallet[1] to manage identities. We can deterministically create a private key from a string like a repo name, and use that private key to create a ChainTree with a DID derived from that key (and hence, the DID is derived from the string). This gives us a mapping from repos to Tupelo ChainTrees. Since the initial "private" key is deterministically derived from the repo name, that initial private key is insecure. The second step of the repo registration process is to submit a ChainTree transaction to transfer ownership of the repo ChainTree to a secure private key. That way, only the controller of the secure private key can make changes to the repo ChainTree, even if anyone can reproduce the original key from the repo name.

[1]: https://keybase.io/warp/warp_1.0.9_SHA256_a2067491ab582bde77...

Exactly

Yeah, it's still early days, but that's part of the eventual plan for dgit. We're starting with decentralized git remotes, but we will eventually enable DAO like functionality like paying in to repos to support them, voting on things like feature/pull requests, and automatic payouts when an independent dev gets one of their pull requests merged.

Anyone can host a Sia node, but only GitHub can manage GitHub: https://support.sia.tech/category/0OpBuOHIVD-hosting

Anyone can run a Sia node, and anyone will (eventually) be able to run a Tupelo node, but only GitHub manages GitHub. It's decentralized because these networks were designed not to be managed by a single entity, unlike GitHub.

Another Dgit deve here. You're right. Git is decentralized, but most people use centralized git remotes like GitHub. Dgit makes using a decentralized git remote easier. Eventually we'll build more decentralized alternatives to other GitHub features, but the most important value proposition that GitHub provides now is as a git remote, so that's what we started with. We've provide a GitHub action that allows you to use GitHub's other features until we build more decentralized alternatives

git is decentralized, but most git remotes are not. This is a decentralized git remote that gets the best of both worlds. It's a _decentralized_ "one true repo".

Error messages have been greatly improved in Clojure version 1.10[1][2]

[edit] more context

1: https://github.com/clojure/clojure/blob/master/changes.md#21...

2: https://mobile.twitter.com/puredanger/status/102810365424144...

This concept is pretty subtle. Rich Hickey does a great job at explaining it (as always) in "Are We There Yet?"[1]. He deconstructs objects into state (attributes) and behavior (methods), and then uses values (or data) to represent state, and functions to represent behavior. Give that a watch a couple of times to get a better handle on what all this means from the Clojure perspective.

[edit] To answer your other question, a value that isn't a collection in Clojure is called a scalar.

1: https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hi...

Clojure has facilities for seamless interop with Java (or whatever platform it's hosted on). A lot of times when inter-operating with Java libraries, you get back an opaque Object with associated methods when you'd normally expect a transparent Clojure map or some other pure data structure if you were interacting with a purely Clojure library. Datafy is just a protocol that allows you to transform those opaque Objects into transparent data structures.

Clojure separates data from the functions that operate on it. In contrast, Objects intertwine those two things. You can roughly think of the "data" part of an Object as its attributes, and the "function" part its methods.

We're planning on formally verifying the algorithm once it stabilizes.

We completely agree with you that, in general, you don't want to attempt to create an entirely new consensus mechanism. As you know, there are generally only 2 (perhaps 3) broad categories of byzantine tolerant consensus that boil down to PBFT and Nakamoto consensus. Ours is a flavor of PBFT designed to reduce message complexity. We also draw from Casper in order to get the incentives and game theory right which would not be considered part of the consensus algorithm traditionally, but must be considered in the DLT space. We're not really reinventing the wheel but rather adapting some interesting research to new problem set (which is consensus, without total ordering). We also plan on fully vetting and formally verifying our implementation before we move into production.

We are still vetting and improving the consensus algorithm, but we're planning on publishing a full TLA+ spec once the algorithm stabilizes.

Queens is a part of Long Island, in the north western corner of it. So is Brooklyn, which is in the south western corner. Long Island City is indeed a neighborhood within Queens though.

Clear and descriptive function names, concise and non-clever code, and a judicious use of well-named and concise helper functions are all way more valuable than docstrings. IMHO docstrings should be used as a last resort if the problem domain is truly complex enough to warrant it.

Docstrings for trivial, well-named functions just get in the way, and if you feel the need to add a docstring to a complex function just after you've defined it, then I think that might be a hint that you should refactor the code to make it more clear and readable instead.

An ns docstring that describes the intent of the api and docstrings for the major public interface functions are a good idea, but a blanket "docstring for every function" rule is a crutch to make up for unreadable, poorly-written code.

Often they want to build their local textile industry. They're still poor, but they realize that undercutting their local production capacity with free handouts has been one of the things keeping them poor.

minksy also developed a theory later on about how emotions play into cognition and intelligence and wrote [1] as kind of a sequel to SOM.

[1] http://en.wikipedia.org/wiki/The_Emotion_Machine

Surprisingly, I agree with my co-founder. "Hacking" the yc application process implies that the poster was able to put much less work into the application than others did through cleverness on the poster's part. The post sounds like he thoughtfully filled out the application in a way that highlighted his strengths and minimized his weaknesses, as everyone else does. He also put a lot more work and thought into it than we, and the other yc founders that I know, did.

Instead of building that application for a whole month, he should have been building his product and landing customers.