narush

They've been publicizing this migration for at least a few years - I think I migrated my migration after a communication in 2020). Not sure what the actual implications are for who controls my data, but I can say: as a very casual Minecraft user, this change was pretty well publicized and rolled out.

P.S. Anyone else who has mostly stopped playing Minecraft but continues to watch Let's Plays on YouTube? I play Minecraft probably once every 3 months, but watch Minecraft content at least once a week...

I’m wondering :-) FYI, I can’t scroll on mobile on this website. I’m on an iphone.

Looking forward to checking it out if you get scroll fixed!

> They went open-source and lost all our IP instantly.

Can you explain what this means? Like - other people copied your work?

Genuinely wondering, OSS noob here...

https://trymito.io. We desperately need some redesign help. Thanks!

If your willing to limit dynamic program behavior, then you get decidability pretty easily. As a really stupid, simple example, consider a programming language where you were allowed at most 5 lines of code, where each can perform operations on a single variable: incrementing or decrementing it. You’ll pretty easily be able to figure out if these programs terminate, all because you limited dynamic program behavior.

With this language, it looks like: they force all dynamically-sized objects (any string, any array) to set a maximum size at compile time, and limit loops to be statically sized (or on the length of one of those static sized objects). It feels like this gets them most of the way.

The missing bit is some reasoning about recursion: I didn’t look close enough to see what they do, but it seems like you could either disallow it (not great, but in the smart contracts I’ve written it’s not been super useful anyways), or you could do some sort of static reasoning about the recursive parameters to the function getting smaller (the gas accounting seems tricky here).

IMHO, the hard part of this language is convincing anyone the compiler is totally bug-free. In as hostile an environment as a blockchain, where a single bug can lead to all your money going bye bye, using a “new” language is a risk most people will choose to avoid, unless there is a seriously good reason to choose this new language.

IMO, decidability is not a killer-enough feature to convince people to take this risk.

Very excited to watch.

If you haven't checked them out, I highly recommend checking out Andreas YouTube channel [1]. It's the most interesting programming content I've ever watched - and I feel like he's honestly taught me a lot about programming!

[1] https://www.youtube.com/c/AndreasKling

Totally agree with this comment. This sort of "no-lock-in" thinking is exactly what inspired Mito [1] (I'm a co-founder, FYI).

Mito is low-code data analysis tool inspired by spreadsheets. When you edit the spreadsheet, Mito generates Python code directly into your Jupyter lab notebook.

The benefit here is that there's no lock in. If Mito support the action the user wants to take, they can use Mito for a quick point-and-click experience. If not, they can just write Python code as they normally do!

[1] https://trymito.io/hn

Cool paper - thanks for posting! I love the typesetting of the math in these old papers - I have no idea how it was done, but it's ~good vibes~ for me.

If you're interested in reading a more recent take on notation, check out this post [1] by Terence Tao on MathOverflow. It's pretty cool, and a shorter read than this PDF - if you're in a rush.

While I'm posting overflow questions I like, check out this gem [2] on parsing HTML with a regex.

[1] https://mathoverflow.net/questions/366070/what-are-the-benef...

[2] https://stackoverflow.com/questions/1732348/regex-match-open...

I spent a while working on a generalized version control system when I graduated two years ago. It was called Saga [1]. Saga - get it? The name was the best bit.

It allowed you to specify a “file representation format,” and then used some messy 2d-and-above longest-common subsequence matching algo [3] I can up with to diff the files, and merge them if you wanted. It was a lovely learning experience I tried to pass off as a startup, and got two of my friends involved as cofounders.

From there, we tried to focus (generalized version control is really hard… technically and otherwise), and pivoted to version control for Excel spreadsheets. At one point we had branching and merging working for XLSX files. But as we began to discover what version of Excel customers used, things got a lot less fun. That + lack of interest led to another pivot.

Anyways, for the past 1 year (just passed!) we’ve been building Mito [3] with our learnings from all those spreadsheet folks we spent time above. Mito is effectively a spreadsheet within your Python environment. It’s absolutely still getting off the ground, but we’re pretty proud of the value we’re delivering to users currently!

[1] https://github.com/saga-vcs/saga

[2] https://github.com/saga-vcs/saga/blob/master/saga/base_file/...

[3] https://trymito.io/hn

Interesting. Appears to be back up anyways :-)

Super cool. This is the opposite angle from the approach we’re taking at Mito [1].

Instead of extending Excel to support more advanced functionality, we’re extending Python environments to support more basic spreadsheet functionality. So: basic Python users doing data science can use a point and click environment that they are more familiar with.

Interesting difference in user base as a result of this opposite approach. I also don’t envy you building an Excel add-in… we tried that first and didn’t love it :-)

[1] https://trymito.io/hn

Does this work on FF? I tried to check out some samples and couldn't see anything.

Works on chrome, but ran long enough that I bounced. Not sure I'm the target customer, though, so NBD there.

Cool stuff, thanks for posting!

Highly recommend the other videos my this channel. Very interesting and wildly detailed presentations of different small-scale framing experiments!

I love this approach and think you're totally right:

> Err towards action over picking the perfect project.

Lots of really cool ideas here. Thanks for posting all of them - I really appreciate it :)

Very cool! I really appreciate this list. I'm currently evaluating what spreadsheet functions to add to my spreadsheet product [1], and I'm gonna add these to the roadmap.

We currently support the functions listed here [2] - and allow you to write spreadsheet formulas that get transpiled directly to Python code!

If y'all have any other reccomendations for functions we should add - let me know!

[1] https://trymito.io/hn [2] https://docs.trymito.io/how-to/interacting-with-your-data/mi...

Are they monthly payments?

Fantastic blog post. I highly recommend reading it in full, and also checking out the work of the European Spreadsheet Risks Group, and Felienne Hermans specifically (referenced in the original post). I've been working on a spreadsheet startup [1] for the past 8 months or so and those folks have a large amount of absolutely upsetting-but-helpful research on spreadsheet usage/errors.

After the past few years working with spreadsheet power users, here's how I like to think about them: 1. Most spreadsheets are just used a lists/trackers [2]. 2. Some spreadsheets are very calculation heavy, and are better understood as complex software projects (usually modeling something; s/o to those PE mfs) than as anything else. 3. Spreadsheets make the transition between (simple list/tracker) and (complex software project very fluid. This flexibility usually means that the (complex software project) that is created is buggy as hell.

Spreadsheets give not-super-technical users an incredible visibility into their data. Spreadsheets give not-super-technical users a way to program data transformations in what I would argue is the most generally intuitive way that exists. Spreadsheets give not-super-technical users tools to build software without introducing them to proper software development methods. Ya know, like maybe a test. Or a code review. Or no global variables. Etc.

If you want to see how we're attacking the spreadsheet problem, check us out. Feedback highly appreciated! [1]

[1] https://trymito.io/hn [2] https://www.joelonsoftware.com/2012/01/06/how-trello-is-diff...

> Funding by setting a price floor [on a project token]

Aka, the reward is the certainty that you'll be able to trade your tokens in for some minimum price. For the end user, at the end of the day, the prize is $$$.

I'm a bit confused by the first paragraph. Are you saying that public good funding problems don't exist (or are solved b/c they are either funded by the government or aren't worth funding)?

If so, I strongly disagree. The OSS that makes up the backbone of all-the-computation-that-occurs-anywhere is certainly a public good; it's also way underfunded!

Yeah I think this is the real point of a nursing home often times: making sure you can get medical care as you age.

The benefits this data structure can give you sound kinda cool, even if I've got pretty much no idea how this data structure works based on the blog post. I've seen issues with fast set membership checks before that result from "Bloom filters having not the most pleasant API" - they can get annoying in practice.

As something related HN might find interesting: Ethereum uses Bloom filters internally within each block to allow users to easily watch for specific "events" that are fired off by transactions. So, for example, you can just look at the Bloom filter in a block and check if your address is in it, and this will tell you if certain types of tokens might have been transferred to your address within this block. As a user, this might allow you to not look at all the transactions in a block if you're just trying to watch for transactions relevant to you.

But the system is a bit broken. Because Bloom filters only do probabilistic checks of set membership (so it might say inclusion when there's nothing included), and because Bloom filters use hashing internally, you can pretty easily fill up the entire Bloom filter and potentially minorly DOS a few clients. A friend and I have a write-up about our attack (here.)[1] We ended up deciding it wasn't high severity, but it was still pretty fun.

[1] https://medium.com/@naterush1997/eth-goes-bloom-filling-up-e...)

This was actually hilarious, and honestly better than half the screens I've designed :-)

Congrats on the launch! Woop woop.

Two questions for y'all:

1. I'm wonder what your thinking is as a new, custodial crypto exchange. It's not that I don't think a custodial exchange can be successful (see: CB), but it seems like if the whole smart contract thesis is right, then decentralized exchanges are gonna eat the world (at least: your world). If you're all-in on crypto, why not build something decentralized/non-custodial? Long-term, how do you see competition against decentralized exchanges?

2. I read your security page, but what's the real deal w/ your security? 2FA and all is great, but giving a service my API keys is, uh, terrifying / something I will pretty much never do. Does anyone have a background in security / have you done an audit? Not to be a total narc, but crypto exchanges are like, big pots of beautiful honey. More details on your security page would be nice, and for many potential users (such as myself), seem quite necessary - hopefully this is helpful feedback and not just a dunk! I might also promote security stuff to the top of the page / more visible, it's at least the first thing I look for on any crypto service.

I've posted on HN about blockchain stuff before (I'm generally aligned on the "very interesting space, fuck scams" mentality) - and I can say is good luck :) Wish you all the best + looking forward to hearing your thoughts

Taking this with a grain of salt, of course, but cool!

Worth pointing out the concept of "healthspan," which is pretty much like it sounds like: how long you stay healthy to do the things you want to do.

Long lifespan seems worthwhile if it's accompanied by a long healthspan as well.

> Venture capitalists are a primary source of vigor [1] for the entrepreneurial ecosystem of Silicon Valley, and venture capital as an asset class largely punches above its weight.

Maybe I'm a bit cynical, but this is the first sentence in a post written by an investor about an investor. So, ya know, I'm a bit skeptical.

The cited paper does very little to make me feel any better. For one, it's not a history paper - you know... the closest bit of academia to the "study of what happened." It's an economics paper that uses some sort of system model to argue for what links / nodes are valuable in the "silicon valley network."

Yeah, nah. Systems like these rely on far to many assumptions-from-no-where to make compelling arguments about how the real world works. One can massage these models to output pretty much any result one wants (tweak the constants a bit in favor of the venture capitalists, if you so desire).

I'll also note I stopped reading the post there. The rest of it might be inspired, but I couldn't make it through that first sentence.

[1] https://www.tandfonline.com/doi/abs/10.1080/0308514090278682...

I think phrasing spreadsheets as 2D code is mostly misleading, as it makes it seem like it's the code's 2D-ness that makes them useful.

Spreadsheets are one way of consuming 2D _data_, which most business data is. They also provide a very easy interface for thinking about basic transformations on this data: the data is very visible, and every transformation you make is therefore very visible as well. Really: it means folks don't have to worry about control flow.

I agree with other commenters as to the effects of 2D code. I've spent the past year talking to 100s of Excel power users, and it's pretty clear: at any scale, spreadsheets get incredibly hard to follow, audit, and maintain.

The best of both worlds, IMO, is a spreadsheet for data visibility, and a program for transformation visibility. I'm a bit biased though, because this is exactly what we're building at Mito [1].

If you want to see more of our thoughts on the topics above - check out this blog [2] exploring the relationships between REPL environments, spreadsheets, and noteboooks!

[1] https://trymito.io/hn [2] https://trymito.io/blog/repl

claiming that it's the code's 2D-ness that makes it beneficial

I'm a co-founder of Mito. Happy to hear any questions / comments / thoughts about this post, or the product more generally!

No matter the quality of the code presented here, thanks to The Economist for posting this! We all really appreciate it, even if we don't always seem like it :)

Even if it seems justified to shit on the code as is (bad style, lack of comments, no tests, whatever), all it does is discourage similar companies / researchers / folks in academia from posting their code as well. So then we end up with the same code, but now no one can see it - which is the worst of all worlds.

Let's support / work towards a culture of sharing our code before anything else. And if there's something you think can be improved, maybe consider opening a PR with improvements to really _show the value_ to all these parties of posting their code!

One thing blockchain scalability conversations often miss is the concept of induced demand [1].

City streets and computer hardware and blockchain throughput. We dream that 'make bigger, make faster' will alleviate congestion in all of these places, and make our commute and compute as fast and cheap as we want it to be.

But in practice, commuters are programmers are blockchain users.

For commuters, if more lanes get added to a local highway, driving to work becomes traffic free - so why not drive when you used to take the train? With all this extra capacity, there's traffic again.

For programmers, faster computers mean less need to be efficient. Less worry about writing efficient code, seemingly as much JSON parsing as one can tolerate, more dependencies, and higher level languages that make programming more pleasant but less efficient. And so computers are 100000X faster than they used to be, but opening a text editor is about as slow as it was 10 years ago.

For blockchain users, it will be the same. As block space increases, the applications users dream up to run on the blockchain will as well. And so transactions will end up costing the same.

That being said, the total capacity will be higher! So we are scaling - I just don't think it's gonna be the utopia it might appear at first glance.

[1] https://en.wikipedia.org/wiki/Induced_demand

Vitalik is consistently one of the most interesting people to follow in the blockchain space. Even his (5+ year) old writing is quite interesting, if nothing else to see how Ethereum's research thinking has evolved over time.

A few questions re: why "Ethereum is not going further than quadratic [sharding]."

The first reason given: there's a minimum number of nodes required for shard for safety guarantees. So, a couple hundred shards, each with 1000 users seems like a limit. But I wonder: 10 years from now, if the blockchain (maybe pipe?) dreams succeed, then why do we expect 1000 * 500 = 5M nodes? This seems like it's quite small.

Especially if running a node on a phone ever becomes reasonable, or at least participating in the data availability process is possible here, then why would we not go further?

The second reason for non-super-quadratic sharding is data permanence. But here, couldn't we design different shards with different appetites for data permanence. Sure, NFTs currently are forever, but I can think of many applications where users do not give a damn about data permanence, and even some applications where users would prefer if data was just forgotten about.

In which case, what's stopping us from saying "these shards, we save. The other ones, who cares about." We would want users to opt into such guarantees, of course, but it seems reasonably possible.

Of course, let's get a good sharded blockchain before we optimize for more.

I'm excited to see how sharding research continues to involve and drives the cost per TX (economic and environmental) down. Consider me a cheerleader rooting for you all!