Console #27
Dogs, Crypto, and an Alternative App Store
dcc
dcc is a proof of concept for a blockchain with variable hash functions for ASIC resistance. Any miner can use whatever hash function they want (in place of SHA256 for bitcoin). Every node must define its own “scale” function, measuring the difficulty of any hash function it chooses to accept.
last commit: 3 days ago, first commit: November 05, 2020
https://twitter.com/paulpgustafson
braft
braft is an industrial-grade C++ implementation of RAFT consensus algorithm and replicated state machine based on brpc. braft is designed and implemented for scenarios demanding for high workload and low overhead of latency, with the consideration for easy-to-understand concepts so that engineers inside Baidu can build their own distributed systems individually and correctly.
last commit: October 15, 2020, first commit: September 15, 2015
AltStore
AltStore is an alternative app store for non-jailbroken iOS devices.
last commit: 4 days ago, first commit: May 09, 2019
https://twitter.com/rileytestut
dog
dog is a command-line DNS client written in Rust.
last commit: 4 days ago, first commit: April 25, 2020
https://twitter.com/cairnrefinery
Memorai
Memorai is a Chrome extension AI that generates questions based on the text you’re reading. It works out the perfect time to quiz you with novel AI generated questions.
last commit: June 12, 2020, first commit: April 11, 2020
logseq
Logseq is a local-first, non-linear, outliner notebook for organizing and sharing your personal knowledge base.
last commit: 2 hours ago, first commit: December 11, 2019
An Interview With Dr. Paul Gustafson of dcc
What is your background?
I’m a mathematician -- my thesis used category theory to answer questions about topological quantum computation. I’ve always been interested in functional programming and type theory, which I view as the unification of mathematics and programming. I like Haskell, Agda, and Python.
What are you currently learning?
A new approach to linear dependent type theory (tutorial, theory, code). They use it for quantum programming languages, but the same framework applies to reasoning about dynamics in general, not just quantum circuits.
Is your interest in linear dependent type theory driven by your interest in quantum computing, or something else?
Actually, I'm interested in it for applications to robotics, believe it or not. Monoidal categories are pretty ubiquitous objects, whenever you have some notion of parallel composition they will show up. In robotics, this corresponds to parallel composition of behaviors (combining a tail controller with a hopping controller, for example). In quantum computing, it corresponds to running two quantum circuits in parallel or sticking two quantum systems together. The internal logic of monoidal categories is called linear logic, probably best known in the programming community for its connection to Rust's borrow checker, or perhaps session types for reasoning about communicating processes.
What made you make the switch to programming languages for robotics and away from mathematics? or was this work largely a continuation of your thesis?
I've always been interested in better tools for thinking, and of course, language is a huge component of that. One of the hugely under-appreciated aspects of modern life is how much it owes to precise mathematical language (whose development had been largely stagnant since Euclid until an explosion in the mid-19th century). Without the notions of sets, vector spaces, manifolds, and increasingly abstract specifications of computing behavior, we wouldn't have modern physics or computer science. At its best, programming language theory follows this line of inquiry -- the pursuit of more precise tools of thought. The connection to pure mathematics is the following: (functional) programming languages -> type theory -> category theory -> mathematics.
A really interesting fact is that the same abstract mathematical field (category theory) applies to both quantum computation (via TQC) and programming language theory (via types).
Are you interested in Noam Chomsky's work in linguistics?
I know of Chomsky's political ideas, but I have only a passing acquaintance with his linguistics work -- although his Merge idea does sound reminiscent of parallel composition. More generally, I'm a huge fan of compositionality.
Do you see any commercial use cases for quantum computing in the next 5-10 years?
Last I heard Google's Sycamore is state-of-the-art. They have some results in chemistry simulation. I could definitely see a useful quantum API popping up in the next decade. The main obstacle is dealing with decoherence as the number of qubits scales up. These slides have a nice overview of the near-term prospects.
By quantum API do you mean something akin to quantum-as-a-service, or something else? If so, aren’t cloud providers already offering that?
While those services are interesting, I wouldn't say they are particularly useful except to tinker around with quantum circuits. There are two prerequisites for a really useful quantum API. First, it would have to be better than classical systems at solving some broad class of problems of inherent value. Second, to scale you would want a decent quantum programming language (not just the circuit description languages that currently exist). As a point of comparison, imagine if to run a program you had to hand-code an FPGA configuration to run all your computationally-intensive code. This could still be super useful for accelerating specific tasks, but it wouldn't be directly programmable by the vast majority of developers. Fortunately, high-level general-purpose classical programming languages exist. We need similar quantum programming languages with intuitively meaningful high-level data types and functions that compile down to quantum mechanics. This is where linear logic could play a role -- as a type system for a high-level quantum programming language.
I noticed you left Princeton for Texas A&M during your undergrad, do you mind if I ask why that was?
Sure. When I was at Princeton, I wasn't really sure what I wanted to do, but I was sure I didn't want to take a traditional path into investment banking or management consulting. I liked CS, but I majored in math because I felt that I learned more in math classes. But, even though I got decent grades, I didn't really fit into the math department. Eventually, I got sick of going to classes I didn't care about (as well as literally sick with pneumonia) and dropped out in the Spring of junior year. Fortunately, my very supportive family helped me get back on my feet.
Let’s talk about dcc, why was dcc started?
I started out thinking about feedback loops. The coding-deploy-iterate loop is the most powerful feedback loop in history, but it’s being harnessed by big tech companies in harmful ways. It seems like blockchains could provide a way out -- a better way to monetize open source. To learn how blockchains work, I coded up dcc, a maximally decentralized proof-of-concept in Haskell.
Are there any overarching goals of dcc that drive design or implementation? If so, what tradeoffs have been made in dcc as a consequence of these goals?
The chain should be as decentralized as possible. Parameters (block size, block rewards, and hash algorithms) should be chosen by the nodes on a block-by-block basis, not a central group of developers. This might cause fragmentation (multiple chains for different groups of nodes), but gives node operators much more freedom (and the potential for ASIC resistance by penalizing ASIC’d hash algos).
Do you intend to eventually launch dcc as a cryptocurrency?
Possibly, depending on community interest.
What is the best way for a new developer to contribute to dcc?
Get the test cases running, and drop me an email.
If you plan to continue developing dcc, where do you see the project heading next?
Either develop a testnet or possibly merge with an existing project focused on decentralization and ASIC resistance.
Any existing projects in particular?
I'm talking to the VertCoin devs, but I'd also be interested in any other suggestions for aligned projects
Where do you see software development, in general, heading next?
More incremental -- the biggest problem with software development today is collaboration friction. We need better type systems, smaller functions, easier forking, and merging.
This Week’s Question
Last Week’s Responses
If you aren't using distribyted, what is currently stopping you?
Like what you saw here? Why not share it?
Or, better yet, share Console!
Also, don’t forget to subscribe to get a list of open-source projects curated by an Amazon software engineer directly in your email every week.