For those who don’t know: the film City of God is based on this, and it’s a great movie. One of my all-time favorites. The directing, acting photography and storytelling are all very well done. Worth anyone’s time.
1. From the perspective of shareholders, and for the moment ignoring taxes, buybacks and dividends are exactly economically equivalent. If a dividend happens, you get some cash. If a buyback happens, the value of your shares goes up. Crucially, the amount by which each share's price goes up is equal to what the per-share dividend would have been. It's a useful exercise to work this out and convince yourself that it's true.
2. Now let's stop ignoring taxes. If a dividend happens, you get taxed that year. If the value of your shares goes up, you don't get taxed that year. Instead, you get taxed whenever you sell, which might be later when you retire and are in a lower tax bracket, or after a period of some years when you get a lower capital gains tax rate.
3. Now let's think about the effect of dividends vs buybacks on the allocation of your portfolio as a shareholder. Neither changes the total value of your portfolio -- that was point number 1, plus just plain old conservation of dollars, modulo taxes -- but a dividend increases the proportion of your investment that's in cash, while a buyback keeps it constant. Let's say you auto-invest all dividends in the S&P 500 or equivalent index fund. Then dividends reduce your ownership stake in the company, while buybacks keep it constant.
For these reasons, most investors prefer (or ought to prefer) buybacks: they have the same economic effect as dividends but allow you to defer taxes to whenever is optimal for you. Also, and this is a smaller point, if a company does a dividend then you have to actively do something (that is, buy stock) in order to maintain the same proportion of your portfolio in that company. In other words, if you want 10% of your savings to be in X, and they do a dividend, then you have to take the cash and buy shares of X. The reason this is a smaller point is that at least in theory you can get your brokerage to do this for you automatically.
There are some nuances where point number 1 fails to hold: signaling, bad execution of the buybacks, and principal-agent conflicts. The big example of that final point is executive compensation tied to specific share prices. I'm not an expert in this area so I don't know, off the top of my head, if there's real evidence either way that this effect is very large, but it's one that people will bring up so everyone who thinks about this ought to know about it.
This is not quite correct. If a dividend happens, the market capitalisation drops by the amount of the dividend, the number of shares remains constant, so the share price dips by the amount of the dividend per share. All investors get the dividend.
If a buyback happens, the market capitalisation drops by the amount of the buyback, and the number of shares drops by the same ratio, keeping the share price initially constant. The money goes to the investors who sell.
Buybacks are nevertheless good for investors who hold. They now have shares in a company whose market cap is 100% growing enterprise, instead of 90% enterprise and 10% bag of money. That means that if the company keeps doing well, the share price will increase faster than it would have done otherwise (it will also drop faster - it's no longer anchored to an inert pile of cash).
The investors who sell are wealthier by amount $X because now they have fewer shares and more dollars.
The investors who don't sell are wealthier by the same amount $X because the shares they kept are worth more, because prices go up.
> keeping the share price initially constant.
This statement is definitely incorrect, unless you're being very technicaly and pedantic about "initially". You can think about it theoretically or you can look at empirical evidence. It is well-supported empirically that share prices go up after buybacks, and in fact they do so quantitatively by exactly the amount necessary for the equation implied above to hold.
No, this is incorrect. Investors like buybacks, so when the buyback is announced, share prices may rise, but certainly not by the amount of the buyback. They don't go up when the buyback gets executed, unlike dividends, which decrease the share price at the moment when they get distributed.
The equations are:
nr_shares * share_price = cash_of_company + value_of_company_excluding_cash.
In a buyback, cash_of_company decreases by the buyback, and nr_shares decreases by buyback / share_price.
Consider the extreme case, a lemonade stand with a bank account with $1M. 1000 shares outstanding, share price $1000. After a buyback of $900K is announced, 900 shares are sold for $1000. $100K remains in the company's bank account, 100 shares remain outstanding, at ... $1000 per share.
> If the value of your shares goes up, you don't get taxed that year. Instead, you get taxed whenever you sell, which might be later when you retire and are in a lower tax bracket, or after a period of some years when you get a lower capital gains tax rate.
This is actually not true in the Netherlands, which taxes unrealized gains on wealth. Quite unique. But NL also features a dividend tax, which politicians tried to get rid off but didn't succeed because it was such an unpopular plan.
> In other words, if you want 10% of your savings to be in X, and they do a dividend, then you have to take the cash and buy shares of X.
Wouldn't the inverse of this be true in buybacks though? If it's economically equivalent then buyback should increase the price and similarly increase the proportion of X in your portfolio - which would force you to rebalance (might have tax implications).
This is great! Lovely to see a clean new codebase implementing quantum chemistry algorithms like Hartree-Fock. I remember using Molpro at my fist job. Venerable and comprehensive it may be, but it is some hoary Fortran code for sure.
This is so poorly written. What is "Ralph"? What is its purpose? How does it work? A single sentence at the top would help. The writer imagines that the reader cares enough to have followed their entire journey, or to decode this enormously distended pile of words.
More generally, I've noticed that people who spend a lot of time interacting with LLMs sometimes develop a distinct brain-fried tone when they write or talk.
Please don't post shallow dismissals of other people's work (this is in the site guidelines: https://news.ycombinator.com/newsguidelines.html) and especially please don't cross into personal attack.
How is it shallow? The commenter asked three questions. That shows that they read the article and are reacting to it. Shallow would be something like, "More AI slop."
They allege these 3 questions aren't answered in the article and then use that as a jumping off point to further allege that using LLMs have damaged the writer's mind, but the article does address each one of their questions and they would've noticed that if their engagement hadn't been skin deep.
So their comment is really a vehicle for them to deliver an insult and doesn't represent significant engagement with the material or a thoughtful digression that could foster curious conversation.
Note that that doesn't mean it's a good article or that Ralph is a good idea.
"develop a distinct brain-fried tone when they write or talk" - I find that using an LLM as a writing copilot seriously degrades the flow of short form content
I actually visited that link, and the answer seems to be
"If you've seen my socials lately, you might have seen me talking about Ralph and wondering what Ralph is. Ralph is a technique. In its purest form, Ralph is a Bash loop.
while :; do cat PROMPT.md | claude-code ; done
Ralph can replace the majority of outsourcing at most companies for greenfield projects. It has defects, but these are identifiable and resolvable through various styles of prompts."
but the contents of PROMPT.md are behind a paywall. In spirit that is not so different from
gcc program.c; ./a.out
while program.c is behind a paywall. It's nearly impossible to reason about what the system will do and how it works without knowing more about PROMPT.md. For example, PROMPT.md could say "Build the software" or it could say "Write formal proofs in lean for each function" or ...
In the spirit of curiosity, I'd appreciate a summary of a couple sentences describing the approach, aimed at a technically sophisticated audience that understands LLMs and software engineering, but not the specifics of this particular system.
Won’t this only work when connected to the internet? So I can’t use it on a flight.
Or if I work in finance, or healthcare, or law, or government, or a hardware design company, I don’t want my files leaving my network. Those are very important use cases, much more important than searching my personal laptop. I want this for WORK, not my little photo collection or notes or whatever.
This is a great use case for modern LLM/embedding models but gotta be local to be actually useful in the places where it’s most needed.
The file browsing is fully offline supported (as in the files get synced locally). We also allow text search offline, but smart search is not yet offline (we need to embed the search prompt), however, we would like to support fully offline use soon!
Many tools offer offline file browsing and full text search. Anything from midnight commander to Alfred to ripgrep.
I think the valuable and difficult thing is high quality, fast, offline semantic search, including indexing (so my files don't go to your servers -- that's an immediate no-go for all the important industries).
I've tried my hand at this a couple times and it's hard! But really hope you succeed, because it would be a big game changer in how we organize and use information. Every company out there would buy this immediately.
I don't think it's that silly. BusyBox packages a bunch of utilities in a single binary. It amortizes fixed costs: a single binary takes less space than 30 binaries that each do one tiny thing.
These are small bits of code, and the functionality is interrelated. The entire thing feels like a calculator, or awk, and seems reasonable to put in one binary.
The Unix philosophy doesn't actually say anything about whether different tools should live in the same binary. It's about having orthogonal bits of functionality and using text as the universal interface. BusyBox is just as Unix as having all the tools be different binaries.
What you’re solving with Claude Code. All I could gather was … something with your notes. Would you mind clearly stating 2-5 specific problems that
you use Claude Code to solve with your notes?
I love obsidian for the same basic reason you do: it’s just a bunch of text files, so I can use terminal tools and write programs to do stuff with them.
So far I mostly use LLMs to write the tools themselves, but not actually edit the notes. Maybe I can steal some of your ideas!
I'd love to learn more about this. What resources/books/articles/code can I look at to understand this more? Or, if you have some time, would you mind expanding on it?
The parts I'm specifically interested in:
1. What the 300 line pool and allocator look like
2. What this means: "BTW the for-case can simply be supported by setting a pool/global boolean and using that to decide how to wait for a new task (during the paralle for the boolean will be true, otherwise do sleeps with mutexes in the worst case for energy saving)"
This stuff is sometimes difficult to search for because people don’t name it or there are many different names.
Arena allocation on windows for example is basically calling VirtualAlloc for a couple gigabytes on a 64 bit system (you have terabytes of virtual memory available) and then slicing it up into sub-ranges that you pass as parameters to threads grouped hierarchically for each cpu and then within that each group of cores that share cache and then single cores for their own cache memory. Lock the software threads to their hardware threads and done. Then for each arena use bump and maybe pool allocators for most stuff. Very basic and little code, much higher performance than most software out there. It’s also why a lot of diehard C programmers find rust lifetime management overengineered and boring btw because you don’t have so many lifetimes as modern C++ code for example.
For the boolean stuff look at the “better software conference” youtube talk about that video game physics engine for example (sorry, I’m on my phone on the jump). Again, old ideas being rediscovered
> In reality what happens is that software which has at any point cared about being portable doesn't use them.
I don't think this generalization is actually true. Fast portable software compiles conditionally based on the target platform, picking the fast platform-specific intrinsic, and falls back to a slow but guaranteed portable software implementation. This pattern is widespread in numerical linear algebra, media codecs, data compressors, encryption, graphics, etc.
> Last weekend I’ve made a simple CLI tool for myself to help me manage my notes it parses ~/.notes into a list of notes, then builds a tag index mapping strings to references into that list. Straightforward, right? Not in Rust. The borrow checker blocks you the moment you try to add a new note while also holding references to the existing ones. Mutability and borrowing collide, lifetimes show up, and suddenly you’re restructuring your code around the compiler instead of the actual problem.
I'd love to see the actual code here! When I imagine the Rust code for this, I don't really foresee complicated borrow-checker or reference issues. I imagine something like
struct Note {
filename: String,
// maybe: contents: String
}
// newtype for indices into `notes`
struct NoteIdx(usize);
struct Notes {
notes: Vec<Note>,
tag_refs: HashMap<String, Vec<NoteIdx>>
}
You store indices instead of pointers. This is very unlikely to be slower: both a usize index and a pointer are most likely 64 bits on your hardware; there's arguably one extra memory deref but because `notes` will probably be in cache I'd argue it's very unlikely you'll see a real-life performance difference.
It's not magic: you can still mess up the indices as you add and remove notes.
But it's safer: if you mess up the indices, you'll get an out-of-bounds error instead of writing to an unintended location in your process's memory.
Anyway, even if you don't care about safety, it's clear and easy to think about and reason about, and arguably easier to do printf debugging with: "this tag is mentioned in notes 3, 10 and 190, oh, let's print out what those ones are". That's better than reading raw pointers.
Maybe I'm missing something? This sort of task comes up all day every while writing Rust code. It's just a pretty normal pattern in the language. You don't store raw references for ordinary logic like this. You do need it when writing allocators, async runtimes, etc. Famously, async needs self-referential structs to store stack local state between calls to `.await`, and that's why the whole business with `Pin` exists.
reply