I don't find that dynamic typing reduces the number of places I need to update stuff. It just changes when the error occurs.
If I change the shape of some data (such as renaming object properties), I'll need to update all the code that used that data, regardless of the type system. Static typing just ensures that I catch those cases at compile time, not runtime.
Just one simple and contrived example I could come up with the five minutes I had available:
JavaScript:
// rename host -> hostname, update ONE place
function connect(opts) {
const host = opts.hostname ?? opts.host; // compat shim
return `tcp://${host}:${opts.port}`;
}
// old call sites keep working
connect({ host: "db", port: 5432 });
connect({ host: "cache", port: 6379 });
// new call sites also work
connect({ hostname: "db", port: 5432 });
TypeScript:
// same compat goal, but types force propagation unless you widen them
type Opts = { port: number } & ({ host: string } | { hostname: string });
function connect(opts: Opts) {
const host = "hostname" in opts ? opts.hostname : opts.host;
return `tcp://${host}:${opts.port}`;
}
// If instead you "just rename" the type to {hostname; port},
// EVERY call site using {host; port} becomes a compile error.
Again, this is just a simple example. But multiply 100x + way messier codebases where everything are static types and intrinsically linked with each other, and every change becomes "change -> compile and see next spot to change -> change" until you've worked through 10s of files, instead of just changing it in one place.
Personally, I prefer to spend the extra time I get from dynamic languages to write proper unit tests that can actually ensure the absence of specific logic bugs, rather than further ossifying the architecture with static types while changes are still ongoing.
In your Typescript example, the solution would be to use your IDE to refactor hosts to hostnames, a process that takes like 2 seconds. You might have problems if the change exists at a service boundry, but in that case I'd just put the transformation at the service boundry, and keep everything the same internally.
> Personally, I prefer to spend the extra time I get from dynamic languages to write proper unit tests that can actually ensure the absence of specific logic bugs, rather than further ossifying the architecture with static types while changes are still ongoing.
I'd argue static typing makes this much easier, because I know any input types (or output types from other components) will be enforced by the type system. So I don't need to bother writing tests for "what if this parameter isn't set" or "what if this function returns something unexpected". The type system handles all of that, which eliminated a lot of tedious boilerplate tests.
> In your Typescript example, the solution would be to use your IDE to refactor hosts to hostnames
Yeah, sure, and with LLMs you can do this, and you can do that. But if we're talking about languages and their features, relying on IDE features feels slightly off-topic.
But regardless, changes is changes, no matter if you, your IDE or your LLM made them. So even if your IDE makes the changes, it seems at least you can now agree that there are more changes needed, it's just that with TypeScript you have a editor who can help you refactor, and with JavaScript you haven't yet found an editor that can do so.
> So I don't need to bother writing tests for "what if this parameter isn't set" or "what if this function returns something unexpected".
Yeah, those unit tests does nothing, and people who write in dynamic languages don't write tests like that either. You test actual logic, in unit tests, and you rely on the signals that gives you.
In fact, I could bet you that if you and me both sat down and wrote the exact same application, one in JS and one in TS, we'd end up with more or less the same amount of unit tests, yet the JS codebase will be a lot more flexible once product requirements start to change.
But again, YMMV and all that, it's a highly personal preference. I don't think there is a ground truth here, different minds seem to prefer different things. I mostly work in environments where the requirements can change from day to day, and being able to adopt to those without introducing new issues is the most important thing for me, so with JS I stay.
> Yeah, sure, and with LLMs you can do this, and you can do that. But if we're talking about languages and their features, relying on IDE features feels slightly off-topic.
Refacoring tools (such as renaming properties) have been supported by IDEs for decades. And in Typescript specifically, the language is designed with these tools in mind, which are developed and distributed directly by the Typescript team. For all intents and purposes, IDE integration using the Typescript language server is a feature of Typescript.
And if somehow these tools don't work, the compiler will catch it immediately! This means I can refactor with confidence, knowing any type issues will be caught automatically.
It seems like you're vastly overestimating the time and effort it takes to change types in Typescript. In my experience it's something that takes basically no time and effort, and has never caused me any issues or headaches.
You're changing the point though, you claimed "I don't find that dynamic typing reduces the number of places I need to update stuff", which just because your editor makes the change, doesn't suddenly make the change not show up in the diff for you and others. A change is a change, regardless of how it's made, unless you don't keep your code in a SCM that is, which I'm assuming most of us do.
I'm not saying it's hard to change types in TypeScript, I understand that your IDE is connected with the language and they're used together, but again my argument was that having types leads to having to change things in more places. Which is true too, and it's a good thing, it's on purpose, and the tools you use help with that, so yay for that! But it's still more changes, and at least for me it's important to be honest about the tradeoffs our choices leads us to.
As I mentioned earlier, I'm fan of static typing in many situations, just not all of them. And I'm not blind to the negatives they can bring too, I guess I just see more nuance in the static typing vs dynamic debate.
Regardless of how dynamic typing is, the contract being enforced stays the same. It's just less enforced by tools. So with dynamic typing, you will have to change the same amount of code if you want your code to stay correct. The only variation in code changes comes from the annotation for the type system.
> So with dynamic typing, you will have to change the same amount of code if you want your code to stay correct.
No, because if a piece of data is pushed through multiple layers you can just change its type at the source and the destination and not in all the layers the data is pushed through. And you can still be correct.
Imagine you have a thing called target which is a description of some endpoint. You can start with just a string, but at one point decide that instead of string you'd prefer object of a class. In dynamic language you just change the place where it originates and the place where it's used. You don't need to change any spot in 3 layers that just forearded target because they were never forced assumed it's a string.
You can achieve that in staticly typed language if you never use primitive types in your parametrs and return types or if you heavily use generics on everything, but it's not how most people write code.
Tools can help you with the changes, but such refactors aren't usually available in free tools. At least they weren't before LLMs. So the best they could do for most people was to take them on a journey through 3 layers to have them make manual change from string to Target at every spot.
In some type systems, you don't need to change it either. Errors will happens only if you've written code that assumes that `target` is a string. If I write a function with the following signature:
fn split(str: string) => string[]
And you called it with
const first_el = split(target)[0]
If you decide `target` to suddenly be an object, then the code you wrote is incorrect, because semantically, `split` only makes sense when the argument is a string. Which is why, even with dynamic typing, you'll see that the documentation of a function will state what kind of parameters it expects.
If you a call chain like `fn1 | fn2 | fn3 | fn4 | split`, Then yeah you need to ensure what reaches `split` is in fact a string. If you're against updating fn[1-4]'s signature, let's say that it's harder to find which function needs to change in a dynamic typing systems.
Dynamic typing is useful for small programs and scripts because they are easy to iterate upon. But for longer programs, I'll take static typing anytime.
Yeah, you are right that ease of drilling down values through the layers is balanced by the need to remember which places actually do something with the value.
While I always liked dynamic languages and probably wrote most of my code in them I don't think they are useful anymore. Tooling got great and LLMs need every chance they get of verifying stuff they hallucinated. At this point I wouldn't mind a language that's strict about typing but other things as well as ownership, protocols, mandatory assertions, tests, code coverage, even some formal verification. As long as I don't have to write them, but LLM does and uses them to check its work, I'm really fond of it.
Are there any examples where a company was purchased via a leveraged buyout and the company went on to be more profitable afterwards? Because the only examples I know of resulted in the purchased company going bankrupt fairly quickly.
First of all, investment banks are awash in capital thanks to 14 years of ZIRP and massive profitability. They don't like keeping cash on hand, so that means they dole it out into investments, some of which will flop.
Second, banks are the primary creditor in these deals, meaning they get paid first. They don't do these deals without ensuring that the company has enough saleable assets to ensure they get their pound of flesh. Lots of companies have billions in pension-earmarked reserves they don't have to pay out on if they declare bankruptcy. Guess who gets first dibs on that cash.
Third, they can shift the risk by selling their interest in these companies to another party. They are not stuck with it forever.
Image you have a goose that lays golden eggs. You could just keep selling the eggs every year but somebody comes up to you and offers you 2 billion dollars now and the public market values your golden egg business at 1.5 billion dollars so it seems fair.
It turns out that if you kill the goose there's a cache of 3 billion dollars worth of eggs within it.
The goose is gone and everybody made money off of it's demise.
---
PE (not always) is effective at finding under-valued companies and ensuring that they record the value on the PE's books.
Because it sometimes works. But it also sometimes destroys the companies.
But the “works” here is to just make PE richer in the short term, not to actually improve the company in the long term. That short term thinking leads to many impractical decisions that have caused bankruptcies
Because the goal is short term profit, not long term business success. It makes absolutely no difference if the company survives the process or not, what matters is that the PE firms extract their money from the process.
I think if you actually reflect on the matter you would realize that PE firms need to be able to sell the business in order to make money, and that they do in fact sell the business for a profit in the majority of cases. The extremely rare cases of yore where you could buy a business for less than the value of its assets and simply sell off the assets and leave the carcass for bankruptcy are long gone.
leverage increases the disparity of returns (so some companies are definitely out of business because the of the leverage put on them) but by far the vast majority of LBO’s are at least moderately successful.
Many sports teams come to mind. Pretty much any F1 team that exists is now worth a lot more on paper than it was purchased for. A few EPL teams come to mind too.
[1]
“ The Glazer family’s acquisition of Manchester United remains controversial to this day.
Their £790m takeover in the summer of 2005 came by way of a leveraged buyout: when a significant amount of borrowed money is used to fund the acquisition of a company, with the debt secured against that company itself.”
I don't think you're right. During its last fiscal year on the stock market, Twitter reported a net loss of $221 million.
We don't have exact insights to X.com's books, but we have credible reports from the Financial Times that they produced over a billion dollars in ebitda in 2024. This is completely possible with a 50% revenue drop. They laid off 80% of the company, something like 6,000 people.
Beautiful turnaround if those figures are reliable, but like Munger calls them, EBITDA tends to bullshit metrics derived by cobbling up bullshit to hide that a company is losing cash.
Just like Figma booking $700M in 2023 profits which was only possible because of the $1b Adobe breakup fee. Proceeded to lose $732m on $749m in revenues the very next year.
A big part of why Twitter needed to cut expenses drastically after the buyout was that it suddenly had an extra >1$ billion of yearly debt repayments to handle.
Did not helped they alienated paying customers (as in companies selling ads) at around the day 2 by literally ignoring them and not providing the service.
IIRC Musk wanted to get an LBO, but wasn't able to find anyone willing to loan the money.
Keep in mind that a LBO is actually a good deal for the bank, because if the purchased company goes bankrupt, the bank can recoup their investment by liquidating the company.
However, that only works if there are assets to liquidate. This can include physical assets, valuable IPs, or favorable lease agreements. In other words, anything that someone else would want to purchase.
Twitter, being a website, doesn't have a whole lot of assets they could sell. Which meant that other collateral was required for Musk to secure financing.
> However, that only works if there are assets to liquidate
Ownership of the company itself can be sold, but this only works if there's someone who believes the company was overvalued. Unfortunately for Musk, Twitter's market cap dropped by tens of billions between the time he locked-in his offer and the deal's effective date. It's hard to find banks to fund your LBO when you're paying significantly more than what the market believes the company is worth.
If you want a deep dive into chess cheating, including a lot of wild stories, Sarah Z put out an entertaining Youtube video [1] a couple of months ago that explores the concept. It's a long video, but well worth the watch.
Nothing Hamas has done justifies what Israel is doing to Palestinian civilians, because collective punishment is a war crime. "But they did it first" is not a valid excuse, especially when trying to excuse mass starvation and bombing population centers.
Is it collective punishment or just really difficult to successful take down terrorists, destroy their weapons, and free hostages when they hide among civilians in a highly dense place? How would you suggest a country like Israel could definitely put an end to Hamas so their citizens are not experiencing risk? And how do you separate the “civilians” from Hamas when they voted for Hamas, support them today, and so on, knowing full well what their goals are (religious supremacy and genocide)?
The fact that there isn't a rail line from the airport to the strip is wild. It would simplify travel for tourists dramatically, and get a lot of hotel shuttles and taxis off the street. There's a reason why even cities with bad public transit usually have a line to the airport, and it's wild that Las Vegas doesn't have one.
"The strip" isn't one place. It's several miles long. It's not walkable for people with luggage. To do what you propose, you'd have to not just build it to the strip, but along the strip, which is a whole different problem. There's not a lot of space to build a rail line there. It would have to be a block or two away at best. And then, well, the stuff on the other side of the strip is now three blocks away. For people with luggage. In 105 degree heat in August, or in sandstorms, or sometimes in snow.
> and get a lot of hotel shuttles and taxis off the street.
No it wouldn't. Those hotel shuttles and taxies are ideal for anyone with luggage as you don't have to carry your own heavy bags with you. The train doesn't want those people slowing things down for everyone as they get all their bags on/off the train.
Airport lines are a good idea because many thousands of people work at airports and thus don't have luggage. They are also useful for travelers taking a short trip and thus don't have much packaged. However Vegas as a vacation destination is expected to have a lot of people with luggage and less people who are light travelers.
Once tourists drop their bags in their room they should be using transit for every trip until it is finally time to return to the airport.
The main hurdle for Linux gaming right now is kernel-level anticheat. Kernel-level anticheat is increasingly common in multiplayer games, and it does not play well with Linux. This makes it difficult to play new multiplayer games on Linux.
Of course it's easy to argue that kernel-level anticheat gives way too much system access for a simple video game. But it's currently the most effective form of anticheat, and I don't see it going away anytime soon.
> This makes it difficult to play new multiplayer games on Linux.
There are so many multiplayer games that don't use invasive kernel-mode anticheat. I and my friends have been playing them for quite a long while now.
I agree that there are games that won't work because their invasive kernel-mode anticheat won't run under Wine or Proton (and their devs haven't bothered to port it to Linux). Honestly? I'm quite fine with that. There are so many great games out there; I'm totally okay with never again playing the insignificant percentage of them that demand full control of my computer.
You're right, and I realize my post implied that multiplayer was a complete non-starter on Linux, which isn't true. Kernel-level anticheat is mostly found in big, mainstream releases (especially competitive shooters). Of course, these games happen to be very popular, which gives them an outsized impact.
Personally, I know that the upcoming Battlefield 6 is making me question if I want to switch to Linux once Windows 10 support dies. For a lot of people, being able to play 99% of games on Linux doesn't matter if they can't play one specific game they enjoy. It's a situation that just sucks all around, and I don't see it getting fixed anytime soon.
> Of course, these games happen to be very popular, which gives them an outsized impact.
On the one hand, true. On the other hand, I wonder how BF6's day 1 demand will compare with that of Silksong!
> For a lot of people, being able to play 99% of games on Linux doesn't matter if they can't play one specific game they enjoy.
Sure, yeah, agreed. And the only thing that's wrong with that is that they can't play the game they want to play.
> Personally, I know that the upcoming Battlefield 6 is making me question if I want to switch to Linux once Windows 10 support dies.
Yeah, BF6 demanding Secure Boot be enabled is fascinating. All that effort and they currently do (and will continue to) have cheaters. Plus, all it takes is one buggy widely-used kernel component to render the whole Secure Boot exercise pointless.
Bear in mind that I'm quite a fan of first-person shooters when reading the following:
It seems to me that the big-name Military-Themed Murder Simulators are all released on both PC and PS5 these days. It seems like many of them support attaching a mouse and keyboard to the console and giving you mouse+keyboard control. Honestly, if I ever get the urge to play one of those flashy-but-not-at-all-good-enough-to-justify-the-price-let-alone-the-invasive-kernel-mode-combination-snoopware-and-backdoors things again, I'll just get a copy for PS5 and attach a mouse and keyboard.
Were I fifteen, I'd be likely to jump through the hoops they're presenting. But, I'm definitely no longer fifteen... and over those years, I've played so many -frequently way better- incarnations of whatever game the big studios are serving up this year. I guess it's a pity for them that years and years of accumulated experience have turned me into something of a low-key snob. ;)
I don't see why you're being so snarky about popular games just to say that if you were to play them, you would do it on the proprietary system, PS5, which you already own. That's not sticking it to anyone at all.
> I don't see why you're being so snarky about popular games...
You misunderstand me. I've wasted a ton of my life playing video games. I've played a huge number of video games. If you enjoy violent FPS games, you've not played many games, and you especially haven't played any very good multiplayer FPS games, you're likely to like this year's AAA Military-Themed Murder Simulator (MTMS). As I mentioned, fifteen-year-old me would have surely enjoyed this year's installment of MTMS, as fifteen-year-old me had played many, many fewer games in the genre than mumble-year-old me has.
If I wrote video-game-storefront video game reviews [0], there's a type of positive review that I'd end up writing for many of the games I play. It goes something like
"If this is the first or one of the first games of this type you've played, then definitely get a copy and play it. If you like the genre at all, you'll have a great time. If you have played many games of this type, then consider playing something else, or maybe replaying one of those games. It's a totally competent game, and there's absolutely nothing wrong with it. But it doesn't do anything or go anywhere that many other games like it haven't already."
There's absolutely nothing wrong with being a competently executed game that doesn't do anything that hasn't already been done before by most of its predecessors. Folks who really want more of the same will enjoy the game, and folks who haven't yet had what you're offering will love what you've done. It's hard to make a competently executed game, and it's dreadfully hard to make a groundbreaking one. There's no shame at all in "merely" making something that's solid and decent.
Hopefully now you better understand what I'm talking about and why? If you're still confused, or things still don't make sense, I'm happy to attempt to answer additional questions.
> That's not sticking it to anyone at all.
Sure? I agree? I'm not of the opinion that I'm sticking it to anyone here. The huge dev shops don't want to make their extremely invasive kernel-mode anti-cheat work on Linux, but are fine with having their software run on the PS5. I don't know if their kernel-mode anticheat runs on the PS5, and I don't particularly care. I'm 110% fine with them doing whatever they feel like to my PS5, which is a dedicated video gaming appliance. I'm not fine with them doing whatever they feel like to the computer I use for my day-to-day business.
Why would I believe that I was sticking it to someone when I pay them money for a copy of the game they made? That'd be a really stupid way to think. That's like book-burner levels of stupid.
[0] ...and maybe that's something I should start doing...
I'm confused by your assertion that you're shocked. Would you quote the parts that shock you? If some of what's shocking isn't what I've written, please do make sure to mention what you believe I intended to convey but did not write down.
The only game I've heard of is Rust, and apparently they just need to include a library or something to that effect to make it work under Wine, but refuse to do so because they think people will cheat on Linux. I'm pretty sure people cheating are mostly cheating from Windows. I don't care about the Rust game enough to be bothered.
But also that's been part of Wikipedia's website for years now, no special browser support necessary. And because it's tailored specifically to Wikipedia, it works great!
Page preview seems nice in theory, but I'm unconvinced it'll be that useful. Web pages just don't have a the level of standardization necessary to automatically grab a useful preview. And I don't think Firefox has a big enough pull to make that sort of standard.
I used to appreciate it (on Wikipedia), but too often it gets triggered by accident and prevents me from reading what I actually want to read. So much so that I had to find some way to disable it (probably by blocking JS via uBO).
Similar story with GitHub "hovercards". They were helpful, but someone recently decided they have to work in the Issues/PR lists too and, again, it just prevents me from reading the very thing I want to read. Had to disable them (everywhere, unfortunately).
But at that point wouldn't it be easier to just search the web yourself? Obviously that has its pitfalls too, but I don't see how adding an LLM middleman adds any benefit.
For medication guidelines I'd just do a Google search. But sometimes I want 20 sources and a quick summary of them. Agent mode or deep research is so useful. Saves me so much time every day.
I've got to ask, do you play much chess? Because this post reads like you don't understand much about chess.
The issue with "solving" chess isn't that there isn't an objectively best move in every position. The issue is that calculating that move is functionally impossible for most positions. That's because chess gets exponentially more complicated the more pieces there are on the board. For example, there are around 26 million positions with 5 or fewer pieces, and over 3.7 billion positions with 6 or fewer pieces.
And most of those positions are distinct. This isn't like a Rubik's cube, where there are a lot of functionally identical positions. Any experienced chess player can tell you that a single piece placement can be the difference between a winning position, and a losing position.
And this complexity is what I love about chess! I love the fact that I can enter positions that no one has ever encountered before just by playing some chess online. I love the fact that deep analysis is possible, but that the sheer size of the possibility space means we can never truly solve chess. Chess strikes a perfect balance of complexity. Any simpler, and evaluating the best move would be too easy. Any more complicated, and evaluation becomes so difficult that it's hardly worth trying.
Which isn't to say that we can't build computers that are very good at chess. A person hasn't beaten a top computer in decades. Magnus Carlson is probably the greatest chess player to have ever lived, and you can run software on your phone that could easily beat him. But there's a wide gulf between "can beat every human alive" and "plays objectively perfect chess."
Any consumer facing AI project has to contend with the fact that GenAI is predominantly associated with "slop." If you're not actively using an AI tool, most of your experience with GenAI is seeing social media or Youtube flooded with low quality AI content, or having to deal with useless AI customer support. This gives the impression that AI is just cheap garbage, and something that should be actively avoided.
If I change the shape of some data (such as renaming object properties), I'll need to update all the code that used that data, regardless of the type system. Static typing just ensures that I catch those cases at compile time, not runtime.
reply