bheadmaster

Thinking alone about fundamentally deep problems can be poweful, but most software problems are not that deep, they follow a pattern, and it's only a question of discovering them. Doing that alone is inherently slower and less efficient than discussing it with a colleague.

AI just serves as a substitute - an artificial conversational partner.

I feel like you consider yourself more virtuous for not using AI for discussion. Would you consider people who don't talk to colleagues at all, but do all the work themselves more virtuous in an analogous manner?

This is one thing I actually do with a chatbot, instead of an agent. Voice mode even.

I start talking to it while doing menial tasks like cleaning or doing the laundry, and I discuss the architectual decisions and options until I come to some resemblance of a plan.

Good side of this approach is that I can't just "skim over" or "copy paste" things - either I understood them and can repeat them myself, or I can't. It takes more time than /grill-me and similar approaches, but it's the only approach that doesn't make me want to claw my brain out.

Whatever the actual reason for choosing the liver was, we can be certain it wasn't its regenerative property, since such proprerty was unknown to the Greeks at the time.

I phrased it awkwardly. Simply put, in Ancient Greece, liver was something like heart in modern society. It was the seat of human emotions.

So by destroying Prometheus' liver, Zeus attempted to destroy his human emotions, including his pride and defiance against gods.

For what it's worth, Prometheus was a Titan, and Titan was immortal, so his liver regrowing the next day wasn't really that special. If eagle fed on his heart, or lungs, they would've regrown too.

The Greeks chose liver because it symbolized the defiance Prometheus had against gods.

No, this is not the first time. Scaremongering by frontier AI CEOs has been going on since ChatGPT came out, every time with a massive investment following.

OpenAI got $10 billion from Microsoft after Sam Altman claimed AI could lead to extinction of humanity.

Anthropic got similar multi-billion dollar funding from Amazon and Google after warning AI could develop biological weapons.

xAI got similarly massive funding after Elon Musk predicted a terminator-style future.

If you don't accept this as "empirical evidence", then there's nothing to discuss.

> Because we can't observe the counterfactual world, this actually is just an assumption.

If you discard all empirical claims categorically due to "inability to observe the counterfactual world", your own reasoning falls apart. Why would you assume people mean what they say?

> Diving their intention also still requires many assumptions about their intermediate beliefs that I find dubious

You're assuming CEOs of multi-billion dollar companies are honest. I find that dubious.

Care to provide a counter-example?

An assumption is something that we can't know, yet assume is true for the sake of coming up with a theory. What we're assuming here is their intention.

The implication (or as you said, "the links"), that talking about how dangerous their product is leads to more money, is true regardless of their intention. They create hype, they get money, that's not an assumption, that's an observation.

The question is only if their intention was to make money, or are they speaking from the heart. That's the assumption we choose.

Occam's razor is about minimizing the number of assumptions needed for a conclusion. In this case, "they believe it" is the same number of assumptions as "they get paid" - just one.

Most of which run the code in a subprocess and use IPC.

In order to have direct function calls, you need to load the plugin's code in your own memory. Which means you expose your own memory to the plugin. Any malicious/buggy plugin could wreak havoc on your program - even managed code doesn't solve that problem in general.

IPC is the natural solution to that - run a process in its own address space and communicate with it via I/O. TCP is not most optimal, but it is uniquous. Same thing with JSON.

In LSP, most of the processing happens in the LSP server anyway - communication overhead between client and server is negligible in comparison to it.

> Which is true as well

Not quite, as if it was, the War on Drugs would succeed. Instead, it failed spectacularly.

People using Meta products are not making an arbitrary choice that happens to be evil. They are using Meta because other people are using Meta (network effect) or because it helps them calm down after a long day (addiction).

You can say they are "technically part of the problem", as in, their usage supports Meta existence in some micro way, but that doesn't warrant the harsh phrasing you've presented in the original comment.

Punishing addicts doesn't solve the social problem of addiction, in the same way that punishing homeless people doesn't solve the social problem of homelessness.

"People who are using this shit of a drug should be aware that they are part of the problem with every line they do, whenever they fetch a bag of cocaine. You are part of the problem"

> It’s dark times for employment currently unless you’ve got a rare nepotism path.

In the civilized society, we call that "recommendation".

It's because we're no longer a burden.

Many parents would gasp at this sentence, but the same parents would likely complain to anyone who'd listen about how negatively their children are affecting their lives.

I've had an idea for an automated verification for a while, but too busy to implement it.

For every property of the system, implement a mock that simulates a system that works, and multiple variations with forseeable bugs (models are fairly good at predicting possible bugs). Then, write a unit tests that pass on the working simulation and fail on the buggy simulations.

This way model ensures reasonably well that the unit tests test what they're supposed to. Then, you use those tests as a verification to guide the model to implement the functionality.

This approach relies on the assumption that the model can design a reasonable architecture composed of independently-testable modules. In my experience, frontier models should be able to do that.

Are there any technical reasons to override native scrolling functionality in the first place?

Make sure to take reporting negativity bias into account. People will speak up when they don't like something, while stay quiet when everything is fine.

I, personally, enjoy Buf. It has solved many frustrations I've had with The Way it was previously done, manually installing protoc plugins, writing arcane flags into scripts nobody wants to touch, working around various quirks, like how protoc produces different output based on which directory you invoke it in, et cetera... I don't quite like the remote plugin model and rate limiting, but using local plugins is easy enough that it doesn't matter.

Buf has made my life easier, and I've actually been using `buf_ls` for a while now in NeoVim. I understand where the criticism of the title comes from, but I don't personally feel it in this particular case. In fact, I didn't even notice it.

I don't even mind the monetized properietary cloud thing, as long as Buf CLI and the related toolchain remains free software, serving the community. Hope you won't do the ol' switcharoo any time soon.

Your comment is AI. My tarot reader gypsy woman flagged it with 95% confidence

Yeah, I'm not interested in decoding what you meant by your aphorism. Either say what you mean or don't.

System V ABI is pretty standardized.

It's possible in the future we will have Rick and Morty style AI in literally everything just because it's so easy to add it.

    Sentient Switchblade: "Hi Beth! You've gotten taller! Shall we resume stabbing?"

Those who can't do, teach.

I explained in detail why value classes will not outdate this criticism. The syntax is not the point - the point is the very fact that they had to add new syntax means that they couldn't retrofit the semantics into the old syntax. Which means it's nowhere near as general and universal solution as would be required to truly make the criticism outdated - in fact it's quite limited. You can't even modify the fields, which is required for almost every scenario where value classes would be useful. For anything non-trivial, you either need to pay the immutability tax or the GC tax.

> Benchmarks prove otherwise

Well, good luck running the benchmarks on your production servers.

My criticism was not "you can't do this" - my criticism was that Java requires an overengineered GC to compensate for its fundamental language flaws that make optimization all but impossible.

Go's GC is nowhere near as complex, and yet it performs much better, because Go decided not to shoot itself in the foot.

I assume you're referring to value classes?

The very fact that Project Valhalla had to create new opt-in syntax for value classes, in order to get what Go does by default on all its types, is the admission of defeat of a herculean battle of attempting to optimize desite fundamental problems with Java's design.

Value classes won't make criticism outdated, because they don't fix any fundamental problems, they just provide an opt-in feature with significant restrictions.

Yeah, they have to be in order to make up for the braindead decision of making every variable a pointer to heap allocated memory.

Go wins not by technical ingenuity, but by simply not making fundamentally bad decisions in the first place.

What do you mean by "strict typing of its index"?

Language is more than just its syntax and features.

The most important "features" of Go are fast compilation, orthogonality of features, and easy development.

Their propositions may "look like everyone else" if you're only looking at surface syntax, but there's a reason why it took 10 years to design an acceptable generics proposal, and the result is that compiling generic-heavy code is almost as fast as compiling plain Go.

Go being strict about features it accepts is not an ideological thing, but a practical one. If Go could have all the features in the world while still being easy to use, fast to compile, and internally coherent, it would. But it can't (see: C++, C#, Python).