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.
I do the same, but without AI in the loop. Just me and my thoughts while cleaning or doing laundry or going for a run. The best designs and architectural choices and algorithms I've come up with in my carreer were developed and/or refined that way.
It's very enlightening, though it requires being comfortable with being alone with ones thoughts. It seems to me many people are not and need constant distractions and/or dopamine kicks.
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.
I don't know about the Greeks but I know a lot of ancient cultures thought the liver was the most important organ (probably because it's full of blood).
For example in Persian poetry the word liver is found pretty much everywhere you would expect to see the word heart.
"You are my liver" is a nice/romantic thing to say to this day.
There's really no knowing why the Greeks chose liver, or some specific Greek chose liver.
It could have been because the liver was regenerative and they were using the titan with the regenerating liver as another reference to humanity, or it could have been as someone pointed out because predators like to eat the liver first, or it could have been that you can take damage to the liver and live for hours afterwards in agony whereas the same amount of damage to the heart or lungs is apt to cause death to come much quicker.
Perhaps there are undiscovered variants out there were the eagle or a serpent or some other animal attacks his genitals, or his eyes.
But at any rate the Eagle ate his liver, it means nothing in particular, and at the same time it means every particular interpretation we can place on it.
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.
Probably not, I don't think I ever read Galen mentioning it, but then again people would get injured in the liver and recuperate better than other injuries I suppose, which makes me think it is surprising if he didn't.
Just went and checked, evidently he never said anything about it.
old American translation of Galen and Hippocrates for anyone interested, as it can be
difficult to find otherwise
But why were those accompaniments chosen for the liver? Because all three foods are high in tyramine, which is toxic if you're on an MAO Inhibitor. Why would Hannibal be on an MAOI? I have no idea, tbqh. They're for depression and Parkinson's, not antipsychotics.
There are a bunch of Japanese words (including a several loanwords from Chinese) that use the liver / gallbladder metaphorically for courage. Both derive from associations between the humours and personality / behavior. I have no idea, however, why both Eastern and Western naive psychology associate gall with, well, gall.
You left out the important part, that Greek influence made it all the way to Japan, in some cases identifiably intact: "[The Greek wind god] Boreas became the Japanese wind god Fujin through the Greco-Buddhist Wardo/Oado and Chinese Feng Bo/Feng Po ("Uncle Wind"; among various other names). The mother deity Hariti [Kishimojin in Japan] was inspired by Tyche."
I'm thinking the Greeks chose liver because it is the first thing that many predators will eat from a kill - large, more nutrient-dense than almost any other tissue, and relatively quick to access.
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.
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.
> 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.
> If you discard all empirical claims categorically due to "inability to observe the counterfactual world"
I don't.
There are a lot of counterfactuals we can observe empirically.
I'm just saying there is no empirical evidence to support the marketing strategy of "tell people our product is going to kill their families". I believe this is the first time it's been tried out.
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.
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.
Fault isolation is good, but are the fault isolation benefits worth everything else though?
Windows COM does have a way to run the server out-of-process with a performance cost, and this fact is transparent to the client (if it only uses COM interfaces and not global variables or something). I assume you can even switch between the modes at runtime (with restarting the plugin).
I think this is a very reasonable question to ask. Language servers are certainly a significant source of slowdowns and editor unresponsiveness, and any time you're doing IPC, that's another source of latency and fragility.
My current Zed editor instance has 5 different language servers running, implemented in at least 3 different languages, some of which require a full VM runtime.
Could Zed (written in Rust) host a full .NET runtime to run the Roslyn language server for C#? Could an Electron-based editor? It feels a bit daunting. Plugins could be native shared libraries, but what happens when multiple language plugins all try to initialize huge process-wide runtimes like .NET or the JVM? Even multiple instances of the Python runtime are going to potentially be stepping on each others' toes.
IPC and separate processes is probably the pragmatic solution for now, even though I would love to live in a world where in-process was more of an option.
WASM could be the solution, but would lock language server authors into the subset of programming languages that can be compiled to WASM, and WASM still looks a lot like IPC in practice. (Zed already uses WASM components for its plugins.)
I think you can totally start a .NET Runtime for a plugin. There are windows explorer plugins written in .NET - I know because Raymond Chen analyzed how they broke things :)
If you have freedom then you have the the freedom to make mistakes.
In Windows globals are tightly scoped to a DLL and cannot accidentally cross over, so multiple python interpreters are no problem if the python interpreter is statically linked in each python plugin.
It’s just much easier for an editor to manage a single interface for plugins over having to host a bunch of very large runtimes.
Also, I doubt that you would have a very great time running both .NET and JVM in the same process. For one, both of them install signal handlers, and both of them do funky things with threads.
Why not implement unix sockets too, since we want to avoid the ip/tcp stack? Now you have two platforms to support for no real gain. Also, LSP applications are shared between projects/users, how you centralize that if each system needs its own installed program and dependencies? Using networking is the path of least resistance and it's drawbacks are well understood between the ones that need to communicate, there's no point to implement IPC based communication.
"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"
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.
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.
Generally I think the person implementing it has a poor native scrolling experience due to poor hardware and/or software and the hijacked behavior seems better to them.
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.
Totally, and we appreciate the sentiment. But the title was meant to be lighthearted, and instead it clearly struck a nerve. That's not our intent, and it was easy to change, so we just swallowed our pride. We rather the conversation be around Protobuf tooling, and not our poor comedy.
And the Buf CLI will always be free and OSS, don't worry!
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.
reply