If that's a substitute for corporate taxes, why even have them at all, instead of there needing to be schemes so specific that they have their own Wikipedia articles to describe them [1]? Either you think that corporate taxes should exist, and therefore companies shouldn't just get to opt out of them based on whether they can make a claim to benefiting the economy via trickling down, or you don't, in which case you might as well just state that directly.
Yeah I guess I'm not the target audience for this because I assumed that "the power problem" was "massive increase in electricity costs for people despite virtually unchanged usage on their part", not "AI companies have to wait too long to be able to start using even more power than they already are":
> Nicole Pastore, who has lived in her large stone home near Baltimore’s Johns Hopkins University campus for 18 years, said her utility bills over the past year jumped by 50%. “You look at that and think, ‘Oh my god,’” she said. She has now become the kind of mom who walks around her home turning off lights and unplugging her daughter’s cellphone chargers.
> And because Pastore is a judge who rules on rental disputes in Baltimore City District Court, she regularly sees poor people struggling with their own power bills. “It’s utilities versus rent,” she said. “They want to stay in their home, but they also want to keep their lights on.”
I understand the instinct but if people seriously think that they are solving any problem by unplugging cell phone chargers, they are simply bad at math. Human time is easily worth more than that, even when working at minimum wage.
That said, it obviously sucks that utility prices are rising for people who can not effortlessly cover that (not to speak of the local pollution, if that's an issue). Maybe some special tax to offset that cost to society towards hyper scalers would be a reasonable way to soften the blow, but I have not done the math.
They are not necessarily bad at math, but they probably aren't electricians or EEs or have ever needed or been asked to calculate how much power a cell phone charger uses.
Mom/Dad used to unplug things and turn lights off, so they do too.
Only because you hate the rich.
I get that it encourages them to share to keep the pitchforks off their lawn, and that noblesse oblige has broken down recently, but property laws are the foundation of our prosperity. If you can't have something that's actually yours (property laws) for you to invest in, then there will be little investment.
Wanting property laws not to give additional advantages beyond those that wealth itself already gives is not hateful. It's also pretty reasonable that the vast majority of people who are not rich might not care about preserving "our" prosperity in the current form. I'm pretty certain there have been plenty of societies with worse quality of life for most people in them throughout history with property laws at least as strict as ours, so it doesn't follow that people would overall be worse off with more egalitarian property rights. This doesn't even address the obvious issues with assumptions that maximizing prosperity is inherently the most important thing; it was arguably more "propserous" to avoid regulating child labor, 40 hour work weeks, minimum wages, etc., but I fundamentally disagree that those would be bad policies even if there were provably shown to reduce "prosperity", whatever that means
> Yet software developed in C, with all of the foibles of its string routines, has been sold and running for years with trillions of USD is total sales.
Even with the premise that sales of software is a good metric for analyzing design of the language (which I think is arguable at best), we don't know that even more money might have been made with better strings in C. You coming justify pretty much anything with that argument. MongoDB (which indicentally is on C++ and presumably makes plenty of use of std::string) made millions of dollars despite having the bug you mention, so why bother fixing it?
> I've always wondered at the motivatons of the various string routines in C - every one of them seems to have some huge caveat which makes them useless.
Which, to me, sounded like it was a surprise that anything written in C could be a success at all given that something as basic as the string handling (which is pretty fundamental) is bordering on useless.
As I put in my other comment, there were plenty of reasons way back in the 80s/90s why C was chosen for a lot of software, and hardly any (if any at all) of those reasons remain nowadays.
> MongoDB (which indicentally is on C++ and presumably makes plenty of use of std::string) made millions of dollars despite having the bug you mention, so why bother fixing it?
Again, that's not the point I was making, no-one said anything about not fixing something because of how much money it has made.
All it comes down to is that a lot of very successful software is very shoddily written, in a variety of languages, not just notoriously memory-unsafe languages like C. Well written software, or software written in a "better" language, might have a better chance of "succeeding" (whatever that means), but that doesn't mean that awful software can't succeed.
>> I've always wondered at the motivatons of the various string routines in C - every one of them seems to have some huge caveat which makes them useless.
> Which, to me, sounded like it was a surprise that anything written in C could be a success at all given that something as basic as the string handling (which is pretty fundamental) is bordering on useless.
I guess to me that seems like pretty big logical leap. It seems equally plausible that they consider C successful and not going anywhere, so they care about improving the way strings are handled (and therefore gave an example of something they would consider better). Your response seems to be trying to defend against an implication that wasn't apparent in what you were responding to, so it wasn't clear at all to me what point you were trying to make.
Given that the C ABI is basically the standard for how arbitrary languages interact, I wouldn't characterize all of the headaches this can cause as just when other languages interact with C; arguably it can come up when any two languages interact at all, even if neither are C.
Arguably the C ABI was one of those Worse is Better problems like the C language itself. Better languages already existed, but C was basically free and easy to implement, so now there's C everywhere. It seems likely that if not for this ABI we might have an ABI today where all languages which want to offer FFI can agree on how to represent say the immutable slice reference type (Rust's &[T], C++ std::span)
Just an agreed ABI for slices would be enough that language A's growable array type (Rust's Vec, C++ std::vector, but equally the ArrayList or some languages even call this just "list") of say 32-bit signed integers can give a (read only) reference to language B to look at all these 32-bit signed integers without language's A and B having to agree how growable arrays work at all. In C today you have to go wrestle with the ABI pig for much less.
From a historical perspective, my guess is that C interop in some fashion has basically been table stakes for any language of the past few decades, and when you want to plug two arbitrary languages together, if that's the one common API they both speak, it's the most obvious way to do it. I'm not sure I'd consider this "worse is better" as much as just self-reinforcing emergent behavior. I'm not even sure I can come up with any example of an explicitly designed format for arbitrary language interop other than maybe WASM (which of course is a lot more than just that, but it does try to tackle the problem of letting languages interact in an agnostic way).
It's probably a good thing that James isn't zero sum, since otherwise he would have an evil twin out there somewhere trying to get people to be more selfish.
Libraries, yes. Tooling around packages/building/managing runtimes? I'm not convinced. Perl has been using CPAN like two decades now, and I wouldn't consider that ecosystem to exactly be an example of "there's only one way to do it". I feel like you're extrapolating in the wrong direction; older languages are less likely to have first party tooling for this, so they're more likely to have multiple ways of doing it, but I don't think there's much evidence that a language that started out with first party tooling will always follow that same trend. I don't think the issue with Python is it's age as much as the tooling it has was just really not good for a long time. People will probably want to replace subpar tooling regardless of the official status if there's a better alternative, but I'd expect that I'm the presence of good enough first-party tooling, people will eventually stop bothering.
I do actually think Go is a bit of an illustrative example here because it started out with just `go get` and liberal use of vendoring, then accumulated a variety of attempted replacements (e.g. godep and dep, which confusingly were not the same thing), but eventually the first party tooling around modules became a thing and after some time it seems like pretty much everyone dropped those interim tools and standardized on the official tooling. I feel like this actually shows that the proliferation of tooling can actually be stopped even if it didn't exist early on, provided that there's a process for making it official.
And sometimes you even have to use the return value the way the function annoates as well instead of just pretending it's a string or whatever when it's not! Having the language tell me how to use things is so frustrating.
[1]: https://en.wikipedia.org/wiki/Dutch_Sandwich?wprov=sfla1
reply