CipherThrowaway

The difference is absolutely not 3 seconds. That's just the lower bound.

In the case that both people are present and available in the chat at the same time, sure, it's 3 seconds. If not, that extra "hi" can add latency of hours or more. Days if schedules and availability line up badly enough.

In the delay introduced by "hi", you've created uncertainty and ambiguity for your counterpart. They have no idea whether your "hi" is the prelude to something trivial, or something important, or whether it might might be relevant to work they were about to start.

"Asking to ask" is far from the biggest communication issue in the workplace, but it is bad etiquette and a very easy behavior to correct - so why not just make the barest effort to adjust the way you communicate to better fit the medium? Save the "Hi"s and "How are you"s for synchronous communication like calls or meetings. Chat has a different set of pleasantries.

In theory it's Coase Theorem / Coasean bargaining. But even by economics standards, this theoretical result has little real world applicability.

I don't think the two PoVs are incompatible. Lower tolerance for mess drives people to clean earlier and more proactively. The labor equity issue is a direct consequence of differences in taste. There are lots of group dynamics that work this way - not just domestic labor.

The real question is: what can you do about it? My claim is that "I have a problem with your mess" is a better starting point than "you have a problem with mess." Some parts of the article get this, and others don't.

> I think there's nothing wrong with seeing your partner struggling with something, talking to them about it and coming up with ideas to help them.

There is something wrong here: and that's assuming your partner is the one struggling. In clinical cases of hoarding and ADHD, that can definitely be the case - but all hints, nags and nudges are useless in these clinical cases anyway.

Fact is that in your day-to-day neat freak vs messy partner situation, the person struggling with mess is actually the neat partner and not the messy one. Most messy people I know, and have worked with, are quite content with mess.

> Antonia Colins, who runs the website Balance Through Simplicity, has two adolescent daughters, one of whom struggles with neatness

Another possibility: the daughter is at ease in both neat and messy environments, but the mother is only at ease in neat ones. In this case, the conflict is being driven by the mother's struggles - not the daughter's.

Taking the unmarried marriage therapists advice and escalating your nagging to email is a disaster idea. You can't performance manage a relationship. Nagging and trying to change people doesn't work. Communicating your needs and reaching compromise does.

Of course not. Only titans of industry and the landed gentry of the executive class are allowed to "move fast and break things", "ask for forgiveness rather than permission" and take "imperfect action rather than perfect action."

It's more morally permissible for corporate decision makers to install a global surveillance complex than for civil servants to attempt to regulate it.

Everyone knows that bad actors will continue to behave badly in the face of the law. This isn't the insight you seem to think it is.

Really, PG's tweet has little to do with game theory or anything else. It is a first-world-problem whinge about having to click through cookie banners. Assessing the "actual outcome" of complex regulation and legislation is a task beyond the scope of a single tweet.

It might be useful for Graham to determine what claim he is trying to make in the first place. Is he rebutting a particular EU representative for boasting about how good they are at regulation? Or is the idea that the EU shouldn't have the audacity to attempt to regulate in the first place?

Agree. How much corporate propaganda are people consuming that legislators are seen as wholly responsible for the bad behavior and malicious compliance actions of corporations?

What does it say about the relationship between businesses and consumers that the first response to this bad behavior is to shout "look what you made them do!"

Seemingly it is everyone's fault except the bad actors themselves.

Good writing can also come out of Markov chains. Or even RNGs - if your novelist has enough time to filter the output.

LLMs can't write good stuff. Human writers can write good stuff. When a good writer uses an LLM in their writing process, that writer can certainly produce good writing.

When an AI hypebro who is otherwise a bad writer uses an LLM in their writing process, they still produce bad writing.

He provides the cost breakdown in the blog.

> You've latched on that specific word and gone off.

No, I haven't. I'm not talking about style, but something deeper. What I'm talking about is something you don't even seem to realize exists in professional writing - which is why you keep thinking I'm misunderstanding you when I am not.

I've worked with professional writers, and nothing in the LLM space even comes close to them. It's not a matter of low quality vs high quality, or benchmarking, or style. It's simply an apples and oranges comparison.

The economics of LLMs for shortform copy will never make sense, because producing the words is the cheapest part of that process. They might become the best way for writers themselves to produce longform copy on the execution side, but they can't replace the writer's ability to work with the client to figure out exactly what they are trying to write, and why, and what a good result even looks like. And no, this isn't a prompting issue, or a UI issue, or a context window length issue, or anything like that.

Elsewhere in this thread someone mentioned how invaluable LLMs are for producing internal business copy. I could easily see these amateur writing tasks being replaced by LLMs. But the implication there isn't that LLMs are any good at writing, but that these tasks don't require good writing to begin with.

It says a lot about SEO copy that this is one of the areas where LLMs low quality doesn't seem to have impeded adoption. There are a ton of shitty content marketers using LLMs to churn out spam content.

>After my trial, I was really wondering how obvious it was that he was doing that and how his clients thought about him knowing how poorly the stuff these LLM's were putting out.

I feel the same way about this stuff as when devs say they push out LLM code with no refactoring or review. Ah, good luck!

Yes, I've used GPT-4. The writing sounds better, but it still sucks at writing. Most importantly, it feels like it sucks just as much as GPT-3.5 in some deeply important ways.

If you use GPT-4 day-to-day, you've probably encountered this sense of a capability wall before. The point where additional prompting, tweaking, re-prompting simply doesn't seem to be yielding better results on the task, or it feels like the issue is just being shifted around. Over time, you develop a bit of a mental map of where the strengths and weaknesses are, and factor that into your workflows. That's what writing with LLMs feels like, compared to working with a professional writer.

Most writers have already realized that LLMs can't write in any meaningful way.

This is part of the problem with the whole discourse of comparing human writers to LLMs. Superficial things like style and tone aren't the problem, but they are overwhelmingly the focus of these discussions.

It's funny to see, because developers are so sensitive about being treated like code monkeys by their non-technical colleagues. But these same devs turn around to treat other professionals as word monkeys, or pixel monkeys, or whatever else. Not realizing that they are only seeing the tip of the iceberg of someone else's profession.

Professional writers don't take prompts and shit out words. They work closely with their clients to understand the important outcomes, then work strategically towards them. The dead giveaway of LLM writing isn't the style. It's the lack of coherent intent behind the words, and low information density of the text. A professional writer works to communicate a lot with very little. LLMs work in the opposite way: you give it a prompt, then it blows it out into verbiage.

Sit down for coffee with a professional copywriter (not the SEO content marketing spammers), and see what they have to say about LLMs.

Ditto. I started out excited about LLMs and eager to use them everywhere, but have become steadily disillusioned as I have tried to apply them to daily tasks, and seen others try and fail in the same way.

Honestly, LLMs can't even get language right. They produce generic, amateurish copy that reads like it's written by committee. GPT can't perform to the level of a middle market copywriter or content marketer. I am convinced that people who think LLMs can write have simply not understood what professional writers do.

For me the "plateau of productivity" after the disillusionment has been using LLMs a bit like search engines. Quick standalone summaries, snippets or thoughts. A nice day-to-day productivity boost, but nothing that's going to allow me to work less hard.

AI still can't do art. Tacky AI generated imagery is mid-2020s clip art, already recognizable to consumers and signalling negative brand associations like "cheap", "scam", "low quality."

If this is the case, it would be more inline with how other complex professions work.

Entry level positions in fields like medicine, law, the sciences, architecture, engineering etc can require years of intensive training before you're skilled enough to take on the role even at entry level.

>Instead it will mean that bosses can fire 75-90% of the (very expensive) engineers, with the ones who remain left to prompt the AI and clean up any mistakes/misunderstandings.

This is the same logic that has driven cheap off-shoring in non-technical companies.

For decades orgs have been able to buy "human-level" (i.e. humans) engineering for a tiny fraction of an engineer's salary, and there have been millions of eager salesmen for off-shore dev shops pushing them to do it too. After seeing the outcomes of this approach, I understand why well-paid engineers remain well paid. And why they'll remain well-paid after the LLM non-pocalypse.

If you think LLMs are so amazing, I would encourage you to see how much you can rely on them to replace human beings in real world scenarios. Not in contrived PR pieces and cherry picked examples but in situations where actual real people would otherwise be working together to deliver commercially valuable outcomes.

You believe you have domain specific insights that allow you to state, with confidence, that LLMs are able to replace a highly technical and well-compensated role at virtually no cost. If that's the case, you're sitting on a gold mine. If I believed that, I'd be starting a development agency tomorrow.

If that was the assumption, then this whole thing makes even less sense. If your operation is already idempotent in its implementation, then wrapping it with this function is the last thing you'd want to do. By introducing at-most-once semantics on top of the call, it would defeat the point of making the operation idempotent to begin with.

The scenario where you'd want to use this `tryOnce` policy is probably the following:

1. You have an operation that is not idempotent and can't be made idempotent, for whatever reason.

2. You would prefer the failure mode of that operation to be that the effect doesn't take place, rather than that the effect takes place more than once.

BTW, you don't need to have an answer for everything. I don't think there has been any miscommunication or misunderstanding of the docs. I think people in this thread, including myself, have accurately identified that you haven't fully thought some of this stuff through. That's fine and normal for a product in this stage, but not being willing to admit it is less of a good sign. Good luck with the startup.

One difference is that you are specifically creating distributed systems middleware, where your audience is going to be using your product in the implementation of a system of their own, and is more likely to understand the terminology and wish to know the exact guarantees and trade-offs being provided.

I find both those comparisons are apples to oranges:

1. Temporal does not claim, on that page, to be able to automatically make your calls idempotent. Instead, it is explaining how you - as the user - can and should write your activities to be idempotent. Take the payment code snippet: you can't just wrap `ExternalPaymentAPI.Process(paymentId, amount)` in an idempotency provider. You have to implement specific idempotency logic inside the activity. This is in line with the distributed systems theory of idempotency.

2. In these docs, Stripe describes an interface for achieving idempotency as an external caller. Since Stripe control the implementation of their own system, it is certainly possible that they have implemented their operations in a way that is truly idempotent. What your docs describe - the ability to make arbitrary operations idempotent by wrapping them - is simply not possible.

I wonder whether you're focusing on the idempotency key as the thing that is wrong here. There is nothing wrong with idempotency keys themselves - they are a great way for APIs to provide idempotency. The problem is that this guarantee can't be provided by a wrapper layer, it requires the operation itself to be written in an idempotent way. This is an example of the age old "end-to-end principle" from networks class.

You mentioned elsewhere that you're still finding the right wording for the product and its benefits. Fair enough. Personally, I think you should probably stop referring to this as idempotency. Maybe describe it as a retry policy, or as a choice between at-least-once and at-most-once. I expect most people with knowledge of - and respect for - distributed systems theory will be completely put-off by this wording.

In distributed systems, the reason idempotency is such a Big Deal™ is that it can be combined with at-least-once delivery to achieve exactly-once semantics. This isn't that. What you're describing as idempotency has the potential to mislead users, especially since you use examples like credit card processing.

Eventual consistency isn't a philosophy, and it's not the idea that race conditions are acceptable. It's a consistency model with specific properties and guarantees.

These races we're talking about don't produce eventual consistency, but inconsistency. Different systems require different levels of correctness, but if you're not familiar with the underlying theory then your trade-offs are going to be uninformed decisions rather than informed ones.

It sounds to me like there are scenarios where calls to, and certainly effects of, "idempotent" functions can take place twice.

I haven't looked at Redlock for a while, but I'm assuming you're all across the historical objections to it from distributed systems researchers: https://martin.kleppmann.com/2016/02/08/how-to-do-distribute...

That's one way of reading it - although I find it's at odds with the heading "Idempotency in one line of code."

If it's the case that the idempotency wrapper is only for operations that are already idempotent, it makes me wonder that the docs couldn't do a better job of communicating the purpose and function. Decorate your idempotent operations.. to make them more idempotent?

Neither method works.

If the framework records the occurrence of the call before the effect of the function, you achieve at-most-once semantics. If it records the call after the effect, you get at-least-once.

The framework might perform its idempotency bookkeeping within the same transaction boundary as the function's side-effects, but this means the function implementation is no longer a black-box. E.g. you can no longer perform arbitrary side-effects while preserving the idempotency guarantees of the framework.

How does the idempotency work? I don't understand how functions can be made idempotent without changing or instrumenting their implementation for end-to-end idempotency.

+1 and was looking for this comment. Pop-psych Dunning-Kruger concept is based on scant research, and the original paper doesn't even make the claim that people think it does.

IMV DKE pop-psych is popular because it enables a kind of second-order superiority complex where you can say shit like, "Research shows that everyone who thinks they're smart is actually a huge dumbass. Actually the really smart ones are the anxiety ridden imposter syndrome devs like myself!"

At least overconfidence and naked condescension required some courage. The insufferable new meta-game of superiority signalling seems to be feigned humility and hiding ego behind the affectation of "knowing how little you know."

This is LinkedIn - not HN - tier content. Comments obviously aren't code, and the idea that they are "as important" is the type of grandstanding you'd perform for a non-developer audience who have no idea what code actually does.

The "why" vs "what" advice is the universal advice everyone has been giving for the last two decades.

I agree with you here. Your example is an abuse scenario. In that case the hurt is the point, there isn't really meaning to it, and it really sucks that it happened to you.

The thing that gives me such a bad vibe from the OP is that this type of behavior is presented as normal in a listening scenario to such an extent that learning to dismiss it is a core listening skill. I think she was either abusive towards the people she expected to listen to her, or the BPD/NPD hypersensitivity to criticism caused her to habitually mistake feedback and boundary setting as cruel and hateful attacks.

Either way, the model of human relationships presented in the OP is completely dysfunctional. It deeply pains me to see it presented as advice.

It's worth reading the paragraph on BPD in that page.

Being conditioned by your BPD partner to excessively validate and center them is not the same as empathy.