wesselbindt

They balance the budget?

It reveals the exact type of mindset that could produce an article like this. All they know is waterfall, so they see agentic coding and think: "you know what we need? More waterfall"

To create goodwill! Nefariously!

I'm nowhere near that level of experience, although I've done both as well. I'm more backend oriented. And my experience has been the opposite. When I ask for backend code, footgun after footgun appears on my screen. With frontend code, much less of an issue, as far as I can tell. Part of me believes this is because I'm less skilled at frontend, and I don't bat an eye when the LLM plops down yet another useMemo (I've since learned that this is rarely needed). But in your case this argument can hardly be made. With 25 years I trust your ability to spot a good design on either end of the stack. So then I don't know where this discrepancy comes from. Maybe my prompting skills leave something to be desired.

Would you describe yourself as more skilled at frontend engineering or at backend engineering?

I'm well aware of its context and original meaning, and I'm very happy to twist its meaning into something Kissinger would disagree with any chance I get.

You guessed wrong. As far as I know, there's no such lobby, and I find your suggestion of its existence to be antisemitic. But the pro Israel lobby is quite open and public. Aipac's spending, for example, is public knowledge, and you can look it up for yourself.

As the saying goes, it may be dangerous to be America's enemy, but to be America's friend is fatal. True in the 60s, still true today.

The idea of injecting more indeterminacy in pipelines is beyond me.

Artisanal astroturfing, using organic humans, used to be the norm. Could be that OP is an actual human doing astroturfing.

Why?

Well, because obviously the finish line of the space race was the Moon.

So, this choice is not super obvious to me. If it was called the moon race or whatever, I'd get it. But in this case it just feels like making up rules after the fact to make sure you "win".

EDIT: I just realized you might be saying this sarcastically. I'm really bad at picking up on that sort of stuff, and apologize if that's the case.

America won the space race? The only milestone where the US got there first was having boots on the moon. Every other milestone (first artificial satellite, first organism in space, first man in space, first woman, first spacewalk, first craft on the moon) was achieved by the soviets first. Taking the one arbitrary milestone where the US did come in first and declare it the finish line feels weird as heck.

Those are not arguments, those are assertions.

I feel like this argument always boils down to explicit vs implicit. It tastes the same as static vs dynamic typing. Personally, I fall well into the explicit camp. I like when I can know stuff about a function without having to read its body, and the bodies of the functions it calls, and the bodies of the functions they call, and so on. And so, I like when I can see from the function signature that it returns an integer, or when I can see from the function signature that it might do IO.

This comes at a cost, namely that of reading five extra characters in a function signature, and I could kind of imagine (truly!) how that gets in the way for some people. There is a cost of writing the five characters as well (and like the author mentions, in a poorly designed codebase, this may have to go down the call stack), but code is read more often than written, so in a sense this is negligible.

Like the dynamic vs static typing debate, I feel like this ultimately boils down to context and personal taste, and some amount of intelligence as well. I'm impressed by the amount of stuff the dynamic typing / non-async crowd is able to keep in their working or long term memory while coding. I don't have that kind of mental bandwidth, sadly.

Having said all that, this argument is disingenuous in that it completely ignores the fact that the async keyword tells you something useful (rather than some made up nonsense like color), and most of the argument basically boils down to "if you ignore the benefits, this syntax has no benefits", and I really don't respect that as an argument.

I've been in the situation a couple of times where we had full control over choosing the frontend framework. Every time we chose React, the main argument was hirability and the fact that the engineers in question were most proficient in React. That is, inertia.

Secondly, when someone new asks me what web framework to learn, I tell them React. And the main reason, every time, is that this is more likely to get them a job, i.e., inertia.

We got here somehow. Clearly, React didn't get here purely on momentum, and must have done something less poorly than the other frameworks. But I think it's hard to deny that inertia plays a big role in its current popularity.

Seems like you dropped something:

Disclaimer: I maintain depsguard

I was under the impression that anyone that uses the MTTR abbreviation knows enough to understand that you need to balance it with change failure rate, deploy frequency, and lead time.

I don't believe you actually think it's odd to not want to run unreviewed code in prod. I accept that you might disagree, but I don't believe this is a take you haven't heard a million times before.

This kind of frivolous nonsense disqualifies bun from ever being a serious option to me. I'm not building any kind of software used in a professional setting on 1M lines of unreviewed code.

I'm guessing they mean US client states, or allies if you want to be polite about it.

A thief would be excited to eat the food they stole

I don't concede that the act of sharing this code is stealing, of course. The act of helping one's fellow man is a good thing. You've made your stance clear, and the very cogent and fairly conclusive arguments people have made against your stance don't seem to land, and I have no interest in repeating that exercise (and neither do you, I'm sure).

But this phrase stood out to me, and in particular that you would choose food as an example. You could've used any other example, like a new hat, or a baseball bat, a tricycle, a mirror, and so on. But you chose food, something people need to survive. Is the case of stealing food not at all morally ambiguous to you? What about the case of a young mother stealing diapers she can't afford?

I've seen stories come out in major news outlets about every man needing to have the same haircut as Kim Jong Un. Something that didn't need lying about imo, but people did anyway. Don't underestimate what people will lie about in times of war.

And some attached pdf that I could have an LLM generate in a minute I wouldn't call a source. I'm talking about a source in the sense of journalism -- something I cannot find for this story.

I'm still confused as to why folks don't just write executable specs.

Are there other sources than a linkedin post? I try to be a bit more critical of information in times of war. God knows we've been lied to before, by all sides. I've seen janitorial schedules be presented as a terrorist sign in sheets.

The destruction of privacy is the whole point.

How did we jump to cigarettes?

Oh, it's an analogy. This is a frequently used rhetorical device where you take a similar analogous setup (maybe hypothetical) to elucidate certain aspects of a situation you're considering.

Nothing you say is in disagreement with the comment you're responding to. And yeah, Apple is doing really well, in part because of their anti competitive practices. Good for them, bad for us.

These responses talking about Apple's bottom line kind of feel like this convo:

Cigarettes are bad, they cause cancer. Philip Morris shouldn't be selling them

Yeah but they sell so many cigarettes! Isn't that great?

I would really hate to work with a blue/red function system. I would have to label all my functions and get nothing in return. But, labelling my functions with some useful information that I care about, that can tell me interesting things about the function without me having to read the function itself and all the functions that it calls, I'd consider a win. I happen to care about whether my functions do IO or not, so the async label has been nothing short of a blessing.

Two of my main CAP theorem pet peeves happen on this page:

- Not realizing it's a very concrete theorem applicable in a very narrow theoretical situation, and that its value lies not in the statement itself but in the way of thinking that goes into the proof.

- Stating it as "pick any two". You cannot pick CA. Under the conditions of the CAP theorem it is immediately obvious that CA implies you have exactly one node. And guess what, then you have P too, because there's no way to partition a single node.

A much more usable statement (which is not a theorem but a rule of thumb) is: there is often a tradeoff between consistency and availability.