Notices by Hrefna (DHC) (hrefna@hachyderm.io)

@dalias Oh 100%

Even if I created something as secure and as well built as 1Password, there's no way people should trust me with something that important all on my own.

@inthehands I don't disagree that I was being somewhat uncharitable/facetious, but I also don't agree with the core of the thesis. Or rather, I don't agree that the impact is so high that it requires a paradigm shift in thinking.

It's kind of like my old thing on tools:

1. Someone looks at the state of the world and goes "this is all too complex! We need to solve this complexity somehow!"
2. They invent a tool. It's fast! It's amazing! Development is now so easy!
3. Everyone starts using it. It's the future. We talk about it in conferences.
4. People realize it needs to work for more than 4 people at a time, that it needs to be secure, that it is still sitting on top of a database that needs structure, it has extensions for different use cases, it needs to be upgraded, etc.
5. It gets to be a nightmare to work with unless you've got a lot of experience or have been doing it for a while.
6. GOTO 1.

This is where tools like BPEL, rules engines, WSDLs, and certain DSLs live. All of which can have their place, even, and be very useful (as I've said before: get a rules engine off the shelf or reinvent one, those tend to be your two options).

But they also didn't end up lowering the barrier to entry overall because of the other problems on the stage: maintainability over time, security, performance, the cost of adding features, etc all sneak up on you.

@inthehands I think the focus on abstractions in the original is missing the mark and giving the AI more credit than it deserves.

As you say: what makes programming hard was never the syntax, and IMO it was also _never the boilerplate_. Boilerplate might make it obtuse, but it doesn't make it hard. Because as you say: there are a lot of things that solve "boilerplate" at different levels.

We've seen eighty million tools on solving this for you. Some of them even work. They all have tradeoffs.

Tools like HyperCard were just amazing though. Encouraging exploration, easy entry. I wish tools like OpenDoc had caught on more as well.

I fully agree we need to learn from vibe coding what people find appealing about it. I just draw the line at a different point than "the abstraction layer programming works on is too difficult."

@dalias This is a different point than the one you made before about them having already promised to donate some amount.

Anyways: https://taxpolicycenter.org/taxvox/who-gets-tax-benefit-those-checkout-donations-0

If they are looking to launder money and commit a tax fraud there are far, far more efficient ways to do it.

@dalias that is incorrect, that would be tax fraud.

@dalias

Okay, and the old joke was:

If I'm pitching to academia or marketing, it's AI.
If I'm pitching to a company exec it's ML.
If I'm actually writing it then it is logistic regression.

AI has gone through iterations on how "cool" it is, but a lot of things start out as "AI" and then get classified as something else. A lot of it rooted in academia. I have an article I saved somewhere that goes into how "AI" can replace our jobs.

They are talking about expert systems, which most people would barely even consider "AI" today, but _were_ solidly considered AI at the time.

Like, roll your eyes at it, sure. But it _isn't the same criticism_ as using generative AI, or using stolen data, or whatever else. Conflating the criticisms does no one any favors.

@adamhotep @raven667 @Nazani @futurebird

@dalias

I've worked with "AI" before it meant "LLMs." I've worked with Machine Learning and MCMC far longer than the Attention is All You Need paper existed.

This use of "AI" is far, far older than LLMs, and has been used as a marketing term in this general direction since at _least_ the 1980s. Ceding everything and criticizing everything under the label just because of LLMs strikes me as not a productive use of time.

@adamhotep @raven667 @Nazani @futurebird

@inthehands Advantages (?) of 20 years of work experience, mostly in small companies :p

@helge My statement has long been:

I don't like a lot about ATProto's approach, but I do understand what they are doing and why it makes sense for what they are trying to accomplish.

But AP's approach is just _too_ fragmented. By being unwilling to make tradeoffs upfront—something that ATProto does, even where I disagree with them or don't want what it is trying to do—it means that it is impossible to use effectively even for things that I think it would be good at.

My biggest frustration in all of this, however, are people who treat AP's approach as an unmitigated good or who think that getting something usably consumer-ready will just happen magically, without respect for the very real costs that come with such a design.

So much this. https://adhd.irenes.space/@ireneista/statuses/01JJMNPMSKB7AHQNKWQMMC1ZNV

@helge That at least is an actually true reason :p

@helge Really I think in general centralization is going to be a lot cheaper. The trick is that the more we push to the edges the worse this gets by orders of magnitude.

Of course this is also made worse by that most groups do not have people who are competent to run these systems.

That's the needle that ATProto is trying to thread and its tradeoffs are all built around that question.

Like if you have a bunch of perfectly spherical individuals running around in a frictionless vacuum sure it makes sense.

But in the real world where you have like… actual networks to deal with, and partitions, and security patches, and spammers, and CSAM, and… to deal with.

We need to consider the degree to which this fetishization of single user servers is meaningfully coherent as a strategy.
https://hachyderm.io/@hrefna/113899314270714595

@helge People fetishize this idea of one person servers, but it's really not a good idea on multiple levels (on SO MANY levels, really) even to the degree that one can technically do it.

@helge There is significant overhead to run just one server, and even higher overhead if that server is mastodon or mastodon-like.

Comparatively: grouping users together on a single server is _very_ efficient from both a connection and cost standpoint, especially if they follow each other.

If you take that same network and you spread it between multiple servers you have orders of magnitude higher resource costs per user and there's basically no getting around that with the current architectures. Not even getting into individual administrative costs (time) per person.

The best argument.
https://mymath.rocks/objects/f39cdaa6-253c-4779-b644-2e9111e402e4

@jdp23

YES!

There are real tradeoffs and real problems that we can discuss. There are in particular significant cultural differences that can be called out!

But that's not the same thing as the sheer number of things that, AFAICT, are just made up out of whole cloth or are being repeated based on comparisons that are barely comparing two types of fruit in what they look at, let alone apples to apples.

@thenexusofprivacy

Also

LEARN TO RECOGNIZE FRIGGIN TRADEOFFS.

You don't have to agree with the tradeoffs, you don't have to like the tradeoffs, but LEARN TO RECOGNIZE WHAT IS BEING TRADED.

I swear to the gods if I see one more "the choice is clear" between BlueSky and Mastodon that deliberately goes out of their way to make claims that ignore the reality of how things _actually work here_ I am going to scream.

@puppygirlhornypost2

Not strictly true.

ATProto allows relays to be optional—appviews could subscribe directly to PDSs.

But it reduces connections, which allows a relay in ATProto to run a fraction of the cost _per user_, even where the aggregate cost is higher (I think one estimate from a while back is that it is on the order of millions of tens of millions of BlueSky users for about the cost of Hachyderm).

AP is also, as implemented rather than as designed necessarily, _hellishly_ expensive per user compared to pretty much every major systems protocol.

@o76923 @FediTips