jcburnham

Betteridge's law of headlines is an adage that states: "Any headline that ends in a question mark can be answered by the word no."

https://en.m.wikipedia.org/wiki/Betteridge%27s_law_of_headli...

tracking down the entity that is paying cash

Cash is what the illegal drug trade runs on, and governments are generally very bad at preventing that.

One interesting data-point about Argentina is that currently about 8% of all physical US dollar bills (About $130 billion) are in Argentina (https://www.forbes.com/sites/afontevecchia/2021/06/28/a-cryp...).

I'm suggesting that a large part of the phenomenon you're describing as "garbage that exploits people" is caused by the asymmetry of information found in new market technologies, and that as those technologies mature, those asymmetries dissipate. And that many market technologies we today recognize as good and wholesome started had that kind of bubble phenomenon when they first appeared.

I think many people here simply don't understand how the past century of corrupt governments in Argentina, on both the right and the left, have ruined the economy of that country: https://english.elpais.com/usa/2021-03-05/argentinas-perpetu...

If the people of Argentina can use cryptocurrency to route around the oppressive and unjust laws they suffer under, I say more power to them.

Of course you can use SWIFT, at the cost of bank fees, opaque exchange rates and waiting a week. You could also take a briefcase full of cash on a plane.

Whereas with crypto, you get transparent fees/rates, transaction confirmation in minutes, at any time of day, with a permanent cryptographic record of payment, and you don't unnecessarily leak information to the recipient's local tax authorities.

Yes, you could do that if the payment volume was high and bidirectional. It doesn't work at all for a company that occasionally has to pay someone in Brazil, but has no revenue or presence in Brazil.

They were fed stories They got fomo and bought in.

But the key factor is that they were they fed stories via a new information medium: The Internet. And the Internet is also where beanie babies could be bought (via ty.com) and resold (via Ebay). An argument could be made that Ebay might not even exist today without the beanie babies phenomenon which gave it early traction.

Tether and Bitfinex are certainly highly dubious and I would not at all be surprised if what they've done rises to the level of fraud. So far they have remained mostly out of the courts, but there's a wonderful quote by @patio11:

Bitfinex and its principals have not yet been indicted by the U.S. Attorney for the Southern District of New York, but crucially, not in the same sense that you have not been indicted by the U.S. Attorney for the Southern District of New York.

https://www.kalzumeus.com/2019/10/28/tether-and-bitfinex/

I definitely am not in any way pro-Tether, and I think the industry/the world would be better off without them. However, I do not think this implies a. that Tether serves no function, b. that their collapse will bring down wider markets or c. that this meaningfully reflects on the ethics of cryptocurrency as a whole.

As far as central banks go, I would love to see the adoption of a central bank digital currency at the Fed, ideally with accounts open to the general public. This would combat the plague of regressive fees at commercial banks, allow future economic stimulus to go directly to spenders, and perhaps even allow people to transfer money over the weekend.

Yeah, and like I said, that's a lazy answer, because it raises the question "Why, actually, was there demand for beanie babies?" It was actually a really complex and fascinating phenomenon (I recommend https://www.amazon.com/Great-Beanie-Baby-Bubble-Delusion/dp/...) from the early days of the Internet and e-commerce. Likewise with the Tulip Mania and the South Sea Bubble (which people often compare crypto to); they're a lot more complicated than "people are greedy/stupid speculators", and are in fact important moments in the development of modern finance and the joint-stock corporation.

The argument presented is very reasonable and requires a rebuttal.

The other comments on this thread are worthless and just shilling crypto.

Let me try to present a rebuttal which hopefully you will not dismiss as a "shill" for crypto.

To begin, Tether is obviously ridiculous and most people, even in crypto acknowledge this. However, Tether is not precisely an unregulated "central" bank, but rather a semi-regulated private bank. I say semi-regulated, because they do have some oversight (https://www.cnbc.com/2021/02/23/tether-bitfinex-reach-settle...). It also has many competitors such as USDC, Binance USD, DAI, which are comparable in size: https://coinmarketcap.com/view/stablecoin/. USDT is less than half of the stablecoin market by capitalization, but it is over 80% of the daily transaction volume of the stablecoin market.

If we dig a little deeper though, you can see that the daily transaction volume of Tether often exceeds its market cap: https://nomics.com/assets/usdt-tether/history. This suggests that most owners of Tether are only holding it for a short period of time, which make sense given that on centralized exchanges like Binance it many, if not most, markets are denominated in USDT as one half of a trading pair.

So why, if Tether is generally understood by the market to be backed by nothing, and run by dubious individuals, is it still worth something? It's not because people are stupid, but because of a combination of 1. the enormous international demand for cryptocurrency assets, 2. the lack of sufficient "backed" digital dollars to efficiently lubricate the quantity of transactions people want to make and 3. Gresham's Law (https://en.wikipedia.org/wiki/Gresham's_law), which says given two kinds of commodity money, people will spend the less valuable one, and save the more valuable one.

It's honestly a fascinating example of a money forming out of the matrix of exchanges in a barter economy, and yes, it's a dubious product that will likely break its peg and crash to nothing at some point. But because the total market cap is relatively small, there's not really any significant contagion or "bank run" risk here (BTC lost more than Tether's entire market cap today and mostly people just shrug and say "that's crypto").

The question I want you and all people who say "crypto is a fraud, ponzi scheme, has no value" to ask yourself is "If I'm right, why is there such demand to buy crypto?". Some crypto-critics argue it is because people are stupid and greedy, but to me that's a lazy and elitist answer. My interpretation is that crypto demand is driven by the same forces that cause people to buy condo's in New York City, London, Vancouver, etc. which then sit empty. It's mostly, right now, a combination of inflation and capital flight.

But there is also a growing sector of the crypto-economy which is capable of doing things which are not feasible in traditional finance (e.g. crowd-funding like Gitcoin, anonymous payments like ZCash, or decentralized money like MakerDAO). I don't think current crypto-asset valuations are justified by that sector, but I am hopeful that in the coming years those use cases will grow and will create extraordinary value for the world.

I'm glad you brought up Wise! I love Wise and use it frequently. However, there are some jurisdictions it simply doesn't work for. For example, there is currently no way for a US company to use Wise Business to pay a Brazilian contractor.

This is not because such payments are illegal, but rather because the Brazilian financial system has poor norms and poor rule-of-law: https://techcrunch.com/2021/03/16/wise-accuses-former-brazil....

Given that cryptocurrencies don’t produce anything of material value

I've read this "crypto has no use-case" meme a lot recently, and it's always perplexed me. Crypto is clearly the easiest way to do international payments right now, particularly for countries with restrictive capital controls, like, for example, Argentina (https://www.bloomberg.com/news/articles/2021-08-13/argentina...).

Sometimes this is qualified as "crypto has no use-case except crime", but what obligation do I, a US person, have to follow or respect corrupt Argentinian regulations?

It's the name of the protagonist from science fiction novel Diaspora by Greg Egan, which is where the quote at the top of the README is from.

In the Truth Mines, though, the tags weren't just references; they included complete statements of the particular definitions, axioms, or theorems the objects represented. The Mines were self-contained: every mathematical result that fleshers and their descendants had ever proven was on display in its entirety. The library's exegesis was helpful-but the truths themselves were all here.

Also it's a little homage to both "orphaned technologies" in the history of functional languages, such as the LISP machines: https://en.wikipedia.org/wiki/Lisp_machine, and to Haskell's "orphan instances" https://wiki.haskell.org/Orphan_instance.

There's definitely some similarities to ATS conceptually, but not that much in the actual implementation, and definitely not in the syntax.

That said, Hongwei Xi is a genius, and ATS is one of the most important and innovative languages of the past decade, despite the crazy syntax (seriously, t@ype for the sort of flat memory types is just bonkers). I'm really looking forward to ATS3 though https://github.com/githwxi/ATS-Xanadu, and I think there's chance it could gain serious traction.

Sure, so I do use petgraph for actually visualizing the lambda DAG graphs, since it's got a very nice graphviz integration: https://github.com/yatima-inc/yatima/blob/059b0abccd0ca54b9a....

You can see the output of that here: https://i.redd.it/94zg24fboyv61.png

(N.B. We removed that module from the language core since we're trying to make that no_std, but we're adding it back to our utils crate soon: https://github.com/yatima-inc/yatima/issues/70)

But we can't use petgraph for the actual computational lambda-DAG because of performance. For example, one thing we get by using pointers is constant-time insertion and removal of of parent nodes (every node in the graph points to their parent). We actually wrote our own Doubly-Linked-List in Rust (it can be done!) to store pointers to the parents for this reason: https://github.com/yatima-inc/yatima/blob/main/core/src/dll.....

There's also memory concerns, given that the lambda-DAG collects its own garbage, freeing space allocated for nodes when no longer in use, whereas I believe petgraph is just `Vec` internally, which would require shrinking, and that would also be slow.

All this low-level pointer manipulation was, tbh, a huge amount of work, but the end result is a performant lazy lambda-calculus reducer with sharing in a few thousand lines of Rust, which means fast lambdas on wherever WASM runs.

(That said, I'm a little bit concerned about cache misses with all the pointer chasing we do, but I haven't yet gotten around to profiling different Yatima expressions to measure this. Would be a great project for an OSS contributor too, so I'll probably make a GH issue for it!)

I find it hard to reconcile these goals with the language you created: Monads, applicatives etc

You know, I've never understood the the "Monad is hard" meme. Monad isn't hard. Functor is hard. Like, really hard, especially when you consider contravariance and covariance. Monad is like a tiny little teaspoon of hard on top of the swimming pool of Functor hard.

But does any of that complexity prevent you from calling `Option::map` in Rust or `Array.prototype.map` in JS? Or from seeing the pattern between them?

"I have an A and a function A -> B, so I can make a B."

"I have a List A and a function A -> B, so I can make an List B."

"I have an Option A and a function A -> B, so I can make an Option B."

"I have an F A and a function A -> B, so I can make an F B."

Is that too steep of a hill for people? I don't think so. It may not be intuitive, but neither is learning to read and write, and it turns out that virtually everyone can do that with enough practice.

Yatima is not an intuitive language, but it is very simple, whereas a language like Python is much more intuitive, but vastly more complicated. My take is that the former set of properties makes for a more learnable system than the latter. Maybe I'm wrong on that, who knows, but to me it seems like a thesis worth exploring.

And you need corporations to build the device you are currently using to reply. We do our jobs on the shoulder of giants. Thousands of corporations in a world-wide link that provide the necessary resources and know-how to build computers. Not sure how that rhymes with "computing should belong to individual users".

I appreciate the intricate dance of capital behind making the devices we're communicating on. That is not what I'm talking about when I say "computing should belong to individuals rather than corporations." I simply mean that users should have control and agency of what they do on the computing instruments they buy, in the same way they have control and agency of what they do with the writing instruments, or musical instruments they buy.

Or in concrete terms, I have nothing against Apple selling me an iPhone, great piece of hardware. But I do think that once I buy the phone, it's mine and I should be able to run what I want on it, without the phone telling Apple what I'm doing. It's a question of mental autonomy and integrity; I'm extending my mind through the device, so if Apple controls the phone it's like they control a piece of my mind.

For a programming language this philosophy informs a lot of decisions, particularly regarding build system servers. Consider for example that in JS npm is owned by Microsoft, whereas in Rust crates.io is owned by the Rust Foundation. I think the latter is better than the former. But I think the way Yatima's package management works over the decentralized IPFS network is better than either.

Our standard library is here! https://github.com/yatima-inc/introit

"vaporware" is a pretty harsh accusation for a project that has:

- A performant lazy functional runtime with sharing implemented from scratch in Rust

- A dependent type system with substructural types

- Parsing, tooling, a standard library, ability to run on the web via wasm

- Content-addressing and serialization to IPLD so that packages can be shared over IPFS

That's what we claim to do in our README, and that's what we do.

It's true that Yatima doesn't have an effect system yet, nor is it production-ready, but it's a pre-alpha programming language project, what's the standard being applied here?

Come join our matrix channel! #yatima:matrix.org https://matrix.to/#/!bBgWgXJqeKuDuiUYWN:matrix.org?via=matri...

I didn't claim that we have solved or will solve the diversity problem, but I did articulate in the README a few ways that I thought Yatima might contribute.

I also don't agree with your characterization of Haskell, Rust and OCaml as being "high-barrier-to-entry" compared to Python. Personally, I find languages like Python much harder to work with given how arbitrary and detail oriented they are. I think for a lot of people that kind of language is fine. Those people are already well served by existing resources.

The people I want to reach are people who have not yet been exposed to a presentation of mathematics or computer science as an elegant unified field, where proofs are programs and theorems are types. This is what I would have responded well to as a kid who detested Math and CS well into my late teens. Much of what is marketed as "accessible" or "educational" in programming languages comes across as patronizing, a lot of visual programming languages are guilty of this. That approach would also not have worked for me.

So what I'm doing instead is building a language that I would thought was awesome when I was 12. Will that work for everyone, who knows? Probably not. But it would have worked for me, and if there are other people out there in the same situation, then that's good enough motivation for me to keep building.

I think the same problems manifest in math, but to a different degree and in a different way. We do have some expectation of universal mathematics literacy, or at least math is a required subject in most schools around the world.

But I don't think that math education is generally very successful at teaching people math, as described in Lockhart's Lament: https://www.maa.org/sites/default/files/pdf/devlin/Lockharts...

My suspicion is that a big part of the issue is the way math is presented early on is really tedious and boring to a lot of people, in a way that could be addressed by theorem provers. I think something like the Xena Project https://xenaproject.wordpress.com/what-is-the-xena-project/ is potentially an interesting development in that regard (though more for undergraduate math than grade school math).

I also don't think this is anyone's "fault" really. I'm more interested in figuring out what might make things better than assigning blame. Nor do I think I personally can fix it single-handedly with a new programming language. If Yatima can move the ball forward a little bit by eventually contributing to a few people learning and falling in love with programming and math, that's more than enough for me.

I wasn't talking about C--, more about how GHC essentially exposes C libs for its primitives. Also want to clarify that Yatima doesn't compile to Rust either.

The comparison to Haskell/C was an imperfect analogy, I was just trying to express that "functional programming language that integrates with Rust" seems like a mostly unfilled niche that Yatima could exist in

Absolutely accepting contributions, come join our matrix channel: #yatima:matrix.org https://matrix.to/#/!bBgWgXJqeKuDuiUYWN:matrix.org?via=matri...

This issue (on improving the test-suite) is a particularly good starter issue: https://github.com/yatima-inc/yatima/issues/37

Sure, if you consider Haskell's runtime (I know that technically GHC /= Haskell, but in practice it's the only Haskell that matters, except maybe something like Asterius) all the primitives are backed by C libraries: https://hackage.haskell.org/package/ghc-prim-0.4.0.0/docs/GH...

Likewise with conventions around pointers, arrays, etc. to the point where if you want to do anything really low-level or performance sensitive in Haskell, you're essentially punching a hole into C. As a random example, within the fast base64bytestring library, you find lots of use of `malloc`, `ForeignPtr` etc.: https://github.com/haskell/base64-bytestring/blob/master/Dat... And of course because this is C there aren't really many safety guarantees here.

The plan with Yatima with its primitives, and eventually when we write an FFI is to integrate with Rust in the same way that Haskell uses C. My hope is that with Yatima's affine types we might even be able to FFI to and from safe Rust (since the borrow checker uses affine types), but this is a little bit of a research project to see how much that works. Even to unsafe Rust though, we have better safety guarantees than C, since unsafe Rust's UB is still more restricted than C's is.

Thanks for the support! I appreciate the difference of opinion here, but for me the "diversity shtick" isn't a shtick. It's a core reason of why I'm doing this project. Our field has big problem: Nearly everyone on the planet uses computers, but relatively speaking almost no one is "computing literate". The opportunity cost of this is just enormous, and I think it's not going to change unless we acknowledge the problem and set a goal to change it. I agree it would certainly be more palatable to just talk about "universal computing literacy" without mentioning the present skewed demographics of our field. But my goal is not to go through life being palatable, I want to actually make a dent in meaningful problems. And in my view, it would be pretty silly to try to solve what's effectively a massive user-experience problem without saying "Our current userbase is X, our desired userbase is Y, how do we get from X to Y?"

If you or anyone else is off-put by that or disagrees with it, that's completely your right, and I respect it.

(Also, by the way, a sample of fanfiction in a cover letter sounds awesome, and a great fit for the kind of creative engineering culture I like to be a part of)

Thank you!

I would dearly love to make Yatima a usable theorem prover, and Lean has been a huge inspiration particularly regarding syntax. But building a usable theorem prover is a huge project, and at minimum will require substantial work on our theory, on type-inference (which is fairly minimal right now) and on advanced features like quotient types or univalence.

On that point, we've done a little exploration on encoding the Path types from Cubical Type Theory as self-types, and I think there's some promising work to be done there. But I know my limits and while I feel very comfortable building a useful programming language that can do a little bit of basic theorem proving, I know that doing a proper job on a real theorem is going to require larger scale resources.

As far as the link from the Self-Types paper, our theory is similar to their System S, but is not the same. Not 100% sure but I think the main relevant difference here is about Leibniz equality, which iirc allows for saying `a == b` when `a` and `b` are of different types. Yatima's Equal type https://github.com/yatima-inc/introit/blob/main/Equal.ya, implements the more standard homogenous/Martin-Löf equality, but this is just a library, not a language builtin.

We really do need to write an actual paper for Yatima's theory though, especially considering that we've combined the self-types from System S with a variation of Quantitative Types a la Idris 2. Writing that paper is likely step 0 of any Yatima as a theorem prover project, until then we should view Yatima as just an unsound functional programming language with some nice type-level features

Oh, yeah, I didn't even mention this on my other comment, haha. Rust doesn't have dependent-types (except outside of a few niche places like const-generics) and only limited/non-user-exposed sub-structural types. There's a whole range of interesting applications that that those features open up, from compiler optimizations to formal verification.

So, I love Rust immensely, but it's a totally different style of programming than a functional language like Haskell. For example, Rust closures are absolutely not the same as pure functions, and if you try to use them that way you'll have a bad time. Another thing is that Rust's approach to garbage collection is "opt-in" (with Rc, etc), which is great for low-level control, but not so great when you're trying to write high-level or non-performance-critical things. And lastly, recursion is Rust is restricted by the stack, so if you try to recurse too much you'll panic. You can manually increase the stack, of course, but this is again a case of having to explicitly handle your resources.

In some sense, Yatima's trying to be to Rust what Haskell is to C. We reuse a lot of the primitives (like ints, uints, chars, etc), but in a separate runtime layer that lets you just use a lambda like a lambda, and not have to worry if you're recursing too much. Now, that comes with overhead, but in a lot of places (like on the web) that's acceptable.

Another thing to think about is determinism. One goal of Yatima is to have each content-id always run the same way given the same inputs. That means we have to forgo using things like hardware floats (or at least not without some complex wrapping) which can cause UB if you try to read their bits (even in WASM).

I think definitely we're going to want to explore both frontend (along the lines of something like https://seed-rs.org/) and backend use cases for Yatima. I'm looking with great interest at https://github.com/lunatic-solutions/lunatic to see if there's a way for us to integrate their lightweight processes. As far as I understand this is along the lines of what https://www.unisonweb.org/ is doing.

The other thing I'm thinking about is smart contracts. Since Yatima is almost `no_std`, we should be able to build it as a pallet for substrate.dev.

Totally a fair point. Honestly I'm not sure the Yatima's actually ready for on-boarding language users, as distinct from language contributors, just yet. Like, if you want to hack on a Rust implementation of a functional language and can figure out a lot stuff from the source, we're just about ready for you. If you want to use the language to build software that's useful for some other purpose, I don't think we're quite there yet. We don't even have IO yet!

But you're definitely right that once we're ready for people who aren't contributors to use the language we'll need code examples, tutorials, a web repl (it's in progress! https://github.com/yatima-inc/yatima/tree/main/web), and all that good stuff. 100% agree on that