The polishing cloth may be a joke, but I will say that I love the nano-texture display on my laptop. Expensive, and whether it's worth it to you is a personal evaluation. But I think it's awesome, and most people I talk to don't even know it's an option!
It's an amazing fact of mathematics that even a vaccine that has relatively low efficacy can completely neutralize transmission if enough people in a group take it.
This is especially true in the case of the flu because it has a relatively low R0 of approximately 1.3, meaning that without intervention/vaccines, each infected individual infects on average 1.3 other people. The vaccine just needs to be effective enough to drive the reproduction rate below 1 for the virus to die out.
We do not have good data on how effective flu vaccines are at neutralizing transmission. But for the sake of argument, let's take these relatively "bad" years for the flu where they prevented 40% of doctor's visits. Suppose that corresponds to merely preventing 40% of transmissions. The other 60% of transmissions still occur.
In that case is it even possible to drive R_eff (the effective reproduction rate of the virus) below 1? It turns out, yes! With an R0 of 1.3 and an effectiveness of only 40%, you stop the spread of the virus after vaccinating only 60% of people.
Parent poster is saying that even though the effect on an individual is low relative to other vaccines, the effect of a whole group taking the vaccine is actually very high.
This the opposite of your understanding. The benefit to the individuals in a group from the whole group taking the vaccine is actually much larger than the benefit to an individual in the group of taking the vaccine solo.
> Combined with the brutal arithmetic at higher R0R_0
R0 , this is a large part of why flu vaccination programs are generally justified on individual protection against illness and severe outcomes rather than on a realistic expectation of achieving herd immunity and stopping circulation.
On the one hand, in a military setting you can feasibly achieve 100% compliance. But if you don't stop transmission (which it sounds like we don't have good data saying it would), you don't get herd immunity.
So I think you're back to just the benefits of reduction in disease, which is not nothing, but it is marginal like I said originally.
I mean, I would say that preventing 40% of disease (depending on what you're measuring, etc etc) is not marginal. I guess I'd turn it around and ask, if 40% is marginal, what number would not be marginal, and why do you draw the line there?
(For me, "marginal" would mean that the costs were roughly equal to the benefits. I think you'd have a hard time convincing me that saving the lives of even just 1% of the people who would normally die from the flu -- between 10k and 50k people a year -- is roughly equivalent to the cost of giving out flu shots. I suppose you could argue that the benefit is marginal to individuals who have a low probability of dying from the flu, and marginal to a society which has relatively low vaccination rates overall.)
The other thing is that, according to the Claude data here, the vaccine is actually relatively effective at preventing the transmission of some flu variants, 50% effective against influenza B! If so, there would be a clear group benefit to that, you only need (1 - 1/1.3) / 0.5 = 46% of people to be vaccinated to achieve herd immunity to that strain.
The relevant question for me would be how many people would be combat ineffective for how long with and without the flu vaccine. Your Claude conversation says things like this:
"The best recent direct measurement is the FLUTES study (JAMA Network Open, 2024), which tracked secondary infections after flu entered US households across 2017–2020. The result: the estimated effectiveness of influenza vaccines for preventing secondary infections among household contacts was 21.0% (95% CI, 1.4% to 36.7%). Note how wide that confidence interval is — the lower bound is nearly zero."
And
"This is consistent with older household work. A 2013 study found no evidence that vaccination prevented household transmission once influenza was introduced; adults were at particular risk despite vaccination — strikingly, 9 of 11 adults with household-acquired influenza were vaccinated in that sample."
So most people on base who were going to get infected and transmit are still going to do so. Some portion of them have a better time with the illness if it does come around, which won't happen all the time. Contrast that with the costs of the program (side effects, time, whatever cons you can think of), and it seems like you might not be in slam dunk territory.
Interesting. I think numerical computing is a narrow enough domain where programs have very well-behaved control flow, which avoids most of the problems of trace compilation. Loops over branchy code, which are really common in general programs, are very difficult to make work well with tracing.
Numerical programs being very stable in terms of control is what enables GPU parallelization and loop optimizations in the long tradition of Fortran compilers. Optimizations like loop tiling, interchange, strip mining, etc aren't going to be easy to do with trace compilation.
Anyway my comment was more directed toward trace compilation in the context of dynamic languages, and there I think it's pretty well established it only works well for small programs.
ML compilers in particular go beyond even the level of stability you would expect from numerical programs. Due to how the SIMT model of thread/warp divergence works, the hardware heavily punishes unstable branches. E.g. if you have 32 threads taking a branch then recoalescing on a barrier -- if they all go the same direction then they can go down the execution pipe as a single bundle, but if 1 takes it while 31 don't, then that's 2x the ex-pipe usage by default (and if you have e.g. a computed-branch, performance goes out the window). Consequently, the whole stack is built around the expectation of stable control flow, even to the detriment of performance (from a local perspective).
ML frameworks even take advantage of this to compute, ahead-of-time, how much memory will be used at different points in the program graph, and thereafter schedule memcpy's to make space as necessary. Of course this only works for well-behaved program classes, but e.g. most LLM architectures fit into that category. Interestingly MoE models don't, since they require data-dependent control flow, thus the recent push towards accommodating dynamism in frameworks (like JAX, which until ~recently couldn't handle it at all).
My feeling about JavaScript is statistically speaking, random JavaScript code is more likely to be spaghetti nonsense than, say, the equivalent Python code. This feeling isn't based on empirical data, tbh it's probably as much anti-JS bias as it is experience with poorly written JavaScript.
Is your criticism of tracing specific to messy, confusing code, with lots of edge cases in the main loop, or does it also hold true for well written code?
I have no experience with compiler design, didn't even take a compilers course in college.
Nah, as titzer said, it's really about general-purpose code being branchy (a good match for CPUs) vs numeric code being heavily parallelized and non-branchy (a good match for SIMD/GPUs). Only a small subset of very specific languages / instructions target the latter (e.g. CUDA and SSE4).
> Whenever I read about formal specs it always seems to me like “write the same tests just in a different way”, or worse, “write the same implementation but in a different way”. [...] Can anyone enlighten me?
A big difference is that formal methods allow you to use the "for all" quantifier.
For example, you might write a unit test that says "foo('abc') returns a string with no trailing whitespace".
But with formal methods, you can prove that "for any input x, foo(x) returns a string with no trailing whitespace".
This is a trivial example, but you could imagine something more complicated, such as "for any program P, compile(P) has the same behavior as P".
Of course, you have to define what "has the same behavior as" means!
>Of course, you have to define what "has the same behavior as" means
And that's really my issue, for example when you define "has no trailing whitespace", you are basically writing a piece of the implementation. Cover all behaviors, and you have basically re-implemented the function, no?
In other words, if I have the full formal spec of f(), isn't that the same thing as having f()?
> In other words, if I have the full formal spec of f(), isn't that the same thing as having f()?
In some cases, however quite often, the spec is much simpler. For instance, it's easy to say that after running sort on some list, that the result is sorted. However, it is very hard to come up with the algorithm to do that from the specification. Sometimes that is even a point. Bubble sort, quick sort, tim sort, we can go on and on. There's a huge number of different sorts that computer science have discovered over the years. They all should have the same result and so you should be able to prove they do the same thing. However, in the real world there are often reasons you would prefer one to another despite all meeting the same spec.
Another obvious example are cryptographic hash functions: if you have a function f(s) = h, you can trivially specify a function inverse_f(h) = s st f(s) = h, and if you can infer a non-brute-force algorithm for that, you’ve just inferred a cryptographical weakness!
I think the key is that, while you may think you have a full formal spec of f(), you actually do not. You have a program written in some language, and that language has its own spec, and the language is compiled to asm which has its own spec, and the asm executes on an architecture that has its own spec, and so on.
So when you write a function like:
func hypot(x, y):
return sqrt(x*x + y*y)
You might think you have "fully specified" hypot, but this is far from true! You have said nothing about what registers will be used, for example. This is not a problem; quite the opposite. It's the whole point of using high-level languages: they let you focus on what you care about. A spec is just a program in a very-high-level language.
I am not sure that the perspective you have taken is the same as what I understood from the parent post; what I took from it is that things like registers, memory locations, ways to implement square root, and so on, are all _implementation choices_ that are not important properties of the specification. You specify that the hypotenuse is the square root of the sum of squares, but whether square root is implemented using Newtonian approximation or a fast inverse square root is irrelevant; whether your first argument is passed in a register or on the stack is irrelevant.
Often, things like resource usage are not specified: running time, memory consumption, etc, aren't relevant enough to appear in a behavioural specification.
If your spec says "f(a, b) returns a + b", but it's just a high-level document you can use to help guide your implementation, integer overflow is just one of many ways your implementation might be inconsistent with the specification. It's still likely that the existence of a formal specification you reference during implementation means that more edge cases have been considered ahead of time than if you just had an informal spec.
If, on the other hand, you prove it but it turns out not to be true (ie, you overflow integers), your proof is wrong. If a machine verified your proof and gave you a big thumbs up, your machine verification is wrong.
If, in Idris, I write "f : (a : Nat) -> (b : Nat) -> (c : Nat * c = a + b)", then I cannot compile an implementation for which I can't show a proof that the result is _always_ the addition of a and b, for all a and b, unbounded by anything but the resources at hand with which to run the program. An implementation subject to integer overflow won't compile.
Or, I could write "f : (a : Bits32) -> (b : Bits32) -> (c : Bits32 * c = a + b)" and implement something where , but then modulo arithmetic on overflow is _part of the specification_, because "+" in there is doing the heavy lifting of being defined as addition modulo 2*32 already; by specification, 4 billion plus 4 billion is ~3.7 billion.
Everything the parent comment mentioned were implementation details that did not affect the correctness of the code.
I just wanted to point out that there are implementation details that DO affect the correctness of the code.
And, of course programs need to run on multiple architectures. So it's hard to do what people seemed to be talking about in this thread and verify code just from the source code.
If you have the luxury of proving the correctness of the CPU, compiler and OS, that should be a big win. Otherwise, it seems to just be another type of testing. Still useful, but calling it verified or proven seems a bit much.
From my perspective, it seems more to be writing another, more complicated program, with more opportunities for bugs, and seeing if the results agree
Well, ideally you proof should've failed because your axioms should be aware that arithmetic operators in the programming language of your choice are operating modulo some large power of two, and thus don't produce correct results for some particular inputs.
Admittedly, this one peeves a lot. Remember when Java's binary search and mergesort (and implementations in many other languages' standard libraries) turned out to have a bug of this kind [0]? Admittedly, the proof was informal, but if you are trying to prove some properties of a program X written in a certain programming language Y, you can't "just assume" that the semantics of Y are different from what they are, right? The integers do overflow in Java, that's explicitly stated in the Java's spec... and that means that a lot of even the most simplistic code has some very non-obvious correctness preconditions, which most of the times, I believe, are simply hoped to be true.
Non trailing whitespace means the string doesn't end with a space. But foo is a function that converts an AST to a string, that's totally different. Or it's a function that loops until \0 and changes all spaces to +
The spec should be a summary of what the impl is supposed to do. You'd want more than just doesn't end with whitespace of course.
> there are 17 space characters in Unicode and another eight whitespace characters, like newline.
And of course, those 25 characters don't include ZERO WIDTH {SPACE,NON-JOINER,JOINER,NON-BREAKING SPACE} and WORD JOINER, which gives you yet another 5 arguably "it's kinda space, right" codepoints which definitely should not be trailing in any reasonable text string.
Property testing is stochastic, which may be fine, but only gives you a statistically (hopefully) high chance of discovering a problem. If you use something like SPARK/Ada, you can actually embed a proof in the code so that you actually know that the code is correct (for what you've proven). PBT scales better than embedding proofs, though, and is highly effective in practice along with fuzzing.
Unless you literally try every possible combination of inputs (which is usually infeasible), property testing can't give you mathematical guarantees about correctness. You can think of it as a halfway house between classic testing and formal verification:
Classic testing: A human comes up with some concrete example inputs for which they know the "right answers" (corresponding outputs). They write code that runs the code under test, gets its actual outputs, and compares them to the desired outputs.
Property testing: A human comes up with a precise way of randomly generating concrete example (input, desired output) pairs. They write some code to describe how to generate the pairs, often using a declarative DSL that describes only constraints on the inputs and outputs, with the understanding that anything not expressly forbidden is permitted, like "The input can be any list of between 0 and 100 integers each between -500 and 500" and "Every integer in the input must appear the same number of times in the output". They then write some more code (often a single line) to ask the computer to use this "spec" to randomly generate, say, 1000 such pairs, or as many pairs as can be checked in 1s. The computer generates the pairs itself, runs the code under test on each input and and checks its output matches the desired output.
Formal verification: A human comes up with a spec that typically describes conditions that must hold for all (input, output) pairs. This may look very similar to, or even exactly like the DSL used for property testing, though in general there are other conditions that can be expressed that cannot be checked with property testing even in principle -- for example, checking that the program always eventually terminates. The main difference is that the code under test is never actually run; instead, the computer analyses the source code itself to attempt mathematically prove that the stated conditions hold. How to actually accomplish this is a field of active research, but one basic approach is called "symbolic execution". To greatly simplify, if we forget about loops and conditionals for a moment, the idea is that we can write down things we know must be true after each statement executes, based on the things we knew must be true before it executed. So for example if x is a variable initially containing any integer (and we ignore overflow) then after the line
x = x * x
runs, we know that x >= 0. To handle conditionals like
if x > 50:
x = 42
something_afterwards(x)
the prover "forks" into two cases: One in which we know for certain that x > 50, one in which we know for certain that x <= 50. At the end of the if statement it then has the task of recombining what is known about the two cases. In this example, the first case lets us conclude that x = 42 by the end, while the second case lets us conclude that x <= 50 by the end, so it could conclude that x <= 50 either way by the time execution reaches something_afterwards(x). Handling loops is trickier but generally involves looking for invariants.
> Choices are made by people who have power and imposed upon people who don't.
In a capitalist society, choices are made according to supply and demand.
In a world where there's a positive supply shock (in this case, there's a lot more programming available for purchase today than there was a year ago), supply goes up. We therefore expect the price for the good to decrease.
This has nothing to do with power or whether people care about xyz. It's a consequence of the economic system we live under.
You can desire to live under a different economic system! That's logically coherent. But if you want the laws of supply and demand not to apply to you, that's what you're asking for.
Honestly I'm getting tired of this narrative. People take the benefits of capitalism for granted (indeed most of us on this forum do very well for ourselves relative to the average person in our country and around the world), but we blame all of its downsides on "bad people".
From where do you get your understanding of the terms supply and demand? They are primarily from classical economics - have you read any? e.g Adam Smith?
And 2 days off was not a system dictated by God, which we are obligated to keep in perpetuity (in fact, most religions dictate 1 day off, not 2).
So, we could, as a society, just choose to make a 32 hour workweek “full time”, and mandate overtime pay after that.
There’s no reason, even under capitalism that we must allow all of the productivity gains to accrue to the benefit of solely those at the top of an enormous pile of wealth.
In fact, I think if we choose to do that as a society, it will end horrifically.
> There’s no reason, even under capitalism that we must allow all of the productivity gains to accrue to the benefit of solely those at the top of an enormous pile of wealth.
I would question the premise that all or even most of the productivity gains of any past technological improvement have accrued to the benefit of solely those at the top of an enormous pile of wealth.
200 years ago 90% of Americans lived on farms. In the early 1900s, it was 40%. Today that number is 2%.
The economic surplus from that increase in productivity accrued to everyone in society, not just the wealthy. (The evidence for this is that we are all living at a higher standard of living today than we were in the early 1800s or 1900s.)
But certainly the positive supply shock was not great news for farmers, many of whom lost their jobs. In the case of AI, I'm asking us -- programmers -- not to make the mistake of saying "this is not a benefit for me, therefore it's not a benefit for society".
> But certainly the positive supply shock was not great news for farmers, many of whom lost their jobs. In the case of AI, I'm asking us -- programmers -- not to make the mistake of saying "this is not a benefit for me, therefore it's not a benefit for society".
I'm not sure about that - farming kind of sucks. I think what the transition away from farming generally looked like was people who had some kind of small family farm, where multiple generations had worked hard all their lives to make a living growing crops, having kids who left the farm to work in some other industry, and making more money that way and having better working conditions (at the price of living a more urban lifestyle foreign to their family back on the farm). When their parents' generation got old and was ready to pass the family farm along, the urban worker generation decided they'd rather not quit their jobs and go back to the family farm; so (perhaps with some feeling of guilt), they sold the land to a large farming conglomerate; and then the next generations who grew up in an urban area doing white-collar jobs simply forgot that their ancestors had ever been farmers.
Something like this happened in my own family - about one hundred years ago, my great-grandfather owned a farm on what was then the outskirts of the bay area. He sold the land when he retired, no one else in my family ever did agricultural work, I only know the story, and the land that farm was once on is now incredibly valuable bay area real estate that is not being used for any agricultural purpose. I have no desire to work in agriculture.
> I would question the premise that all or even most of the productivity gains of any past technological improvement have accrued to the benefit of solely those at the top of an enormous pile of wealth.
The historical automation story seems to be that technology replaces workers, and those workers typically end up taking lower-paying jobs:
"replacing workers with technology “explains 50 to 70%” of the increase in inequality from 1980 to about 2016."
They point out a disappointing aspect of some technologies (self-checkout), which seems to be that not only are workers displaced, but customers also experience degraded service (probably without a new benefit such as a discount for using self-checkout.)
> The historical automation story seems to be that technology replaces workers, and those workers typically end up taking lower-paying jobs
As I said, when farming became more efficient, it wasn't great to be a farmer.
But when I say (and I assume everyone else here also says) "I don't want to go back to a world where 90% of people had to be farmers" (because farming was so inefficient), that's another way of saying, the world that farming efficiencies gave us is richer / more preferable overall than the previous world. In other words, the economic surplus did not go exclusively or primarily to the richest.
I expect the same will be true for AI. I think our society should do more to help the displaced. But I do not want my grandchildren to live in a world where, 100 years from now, 90% of people are still doing jobs that could be done by a computer, but we choose for the computer not to do them. Just like I wouldn't want to have to be a farmer.
> As I said, when farming became more efficient, it wasn't great to be a farmer
What you seem to be saying is that consolidation of the farming industry into fewer producers with higher productivity was good for food buyers and society at large, which might be true but doesn't contradict GP's point that when their company earns $100 more due to improved employee productivity, approximately $0 of that will be paid to the employees, so they find little reason to celebrate.
The link I posted makes somewhat different yet important points: first, the arc of automation seems to tend toward increased inequality (and a hollowing-out of the middle class); second, automation may provide a markedly worse (but cheaper) replacement for the thing it replaces. Even in the case of farming, many fruits and vegetables are less nutritious than they were 100 years ago - perhaps effects of selective breeding (such as for size, shelf-life/durability, resistance to pests/pesticides/herbicides/etc.), soil depletion, environmental changes, etc.
> In other words, the economic surplus did not go exclusively or primarily to the richest.
That was in large part due of strong leftist movements and states that forced the capitalists to share the increasing wealth. WW2 and the resulting labor shortage and other special circumstances contributed as well. Currently no such movements and circumstances exist. Globalization and the resulting free movent of capital has put capitalists in a better position to direct the extra wealth for themselves than ever before. A global movement is required to get a meaningful share of the increased surplus to the workers now, and that is very hard to do. The market will not do it on its own, as the demand for human labor eventually decreases due to automation.
> I would question the premise that all or even most of the productivity gains of any past technological improvement have accrued to the benefit of solely those at the top of an enormous pile of wealth.
That would be relevant if I stood for that premise, but I don't and I wasn't putting it forward.
I was responding to your earlier claim:
> But if you want the laws of supply and demand not to apply to you, that's what you're asking for.
I was disagreeing that this was what was being asked in the present moment. What was being asked in the present moment ("can we have a day off") is very similar to what was being demanded in the past.
In the past, workers demanded to share in the wealth and productivity that was being created through technological gains. And so, I agree with you, workers in the modern era have benefited massively from past technological gains. But that wasn't an accident. Those gains were earned through the blood and sweat of workers demanding to be included in those gains.
And so, to ensure that these present gains continue to be distributed more equally, we need to continue applying the pressure that was applied in the past.
But that's not a rejection of the the laws of supply and demand, it's at a social layer before the economics of supply and demand apply. It's at the political and social layer of how much work we expect an individual worker to put forward into society, which is a major factor in determining the amount of supply of work available.
It's a political decision—totally separate from a rejection of capitalism—of how many hours a "full week of work" is. It is not a rejection of capitalism to set the "full work week" to 48 hours, or to 40 hours, or to 32 hours.
> The economic surplus from that increase in productivity accrued to everyone in society, not just the wealthy.
Sure, a poor man with two dollars is richer than a poor man with one dollar.
And yet the man handing out the dollars had 100$ in surplus when he was handing out 1s and now that he's handing out 2's he's got 1,000,000,000.
Look at the wealth disparity. Even if quality of life has increased, it's not wrong for the people delivering that increased quality of life (workers) to also demand a requisite slice of the pie.
In fact, I see no reason why the pie should be shared with wealthy non workers at all. Were they necessary for the increased quality of life?
On top of that, it's a global economy. Expand beyond the USA and include in your analysis how life has changed in imperialized nations that now function as cheap labor sources for our factories that pollute the local environment while exploiting workers for absurdly low wages and bad working conditions.
> Expand beyond the USA and include in your analysis how life has changed in imperialized nations that now function as cheap labor sources for our factories that pollute the local environment while exploiting workers for absurdly low wages and bad working conditions.
Agreed, let's do that! Here is the economic history of the developing world over the past 70 years.
Pick any metric you care about: number of people living on less than $1/day, literacy, maternal mortality, access to birth control. It has dramatically improved in the developing world over the past 70 years or so.
Putting the poverty line at 1$ a day, or saying people crossed from 2$/day to $3/day is "poverty decreasing," lets people get these self-serving numbers. Poverty declined, relative to what threshold? Do these people have secure housing, medical care, education, political power, in line with their contributions to the global market they've been shoved into?
People being moved from centuries old homes distributed across agrarian geographies into slums, that's improvement?
People living side by side to polluting factories that poison their water, that's improvement?
These people are foisted into a global supply chain, their economies changed into e.g. unsustainable cash crop or similar fragile-to-price-shock products, and themselves thrust into market dependence without any labor security since outside entities show up, exploit while it's profitable, then disappear without leaving any meaningful industrialization to the overall nation. Not to mention there's still a lot of people being straight up enslaved.
> Look at the wealth disparity. Even if quality of life has increased, it's not wrong for the people delivering that increased quality of life (workers) to also demand a requisite slice of the pie.
Sure, but the argument being made is that "productivity gains accrue to the benefit of solely those at the top of an enormous pile of wealth."
That is simply not true. Across the entire world, from rich countries to poor countries, economic development, driven in large part by technological development, has resulted in a dramatic improvement to everyone's quality of life.
The way some people talk about it, it's as though they wish they were middle class in the 1920s instead of in the 2020s. People are so. much. richer. today. In ways that really matter, like education, retirement, ability to travel the world. MEDICINE.
I get that it still sucks today. The only point I'm making is that it's false that the historical economic surplus has accrued "solely" (or even, mostly) to the wealthiest. It's not true.
Both can be true. Standards can both have improved since the 1920s and income inequality can be equivalent or worse than the gilded age. This would be coherent with improvements mostly being funneled to the top, while some benefits accrue throughout the economy.
However the story is much more dynamic and interesting than that, with income inequality shrinking until the late 70s and early 80s, then expanding drastically until now, half a century later. That period of lower income inequality is mostly why things got better for the working class (but science and technology have marched on regardless).
> I get that it still sucks today. The only point I'm making is that it's false that the historical economic surplus has accrued "solely" (or even, mostly) to the wealthiest. It's not true.
It is, though, if we talk scale. The rich went from having big houses in the 1920s to being sent into space, or building private libertarian colonies, or buying elections, or potentially increasing their lifespan a few decades, in the 2020s. The working class went from working 40hrs a week until age 64 when they retire in a house they own, to working 60hrs a week until they die, but hey, that death might be at an older age!
The improvement disparity between the two makes the improvement for the working class insignificant enough to be dismissible. I don't buy into the idea that the working class should be grateful that the scraps now have better seasoning.
I mean really, just look at the wealth gap. Imagine how much better the lives of everyone could be if that wealth was distributed better! Fuck a 20 hr workweek, what about 5?
I don’t want to go back to the past, I want to go toward a future that looks good and fair for regular people. Technology doesn’t provide some divine mandate to build whatever will make the owners more money with no regard for people or the planet.
> I want to go toward a future that looks good and fair for regular people.
Do we agree that moving towards a future that's somehow "more advanced" as compared to the present (i.e. isn't going back to the past) would likely require giving up some land, water, and energy? That is, that progress is always a trade-off?
We don't have to agree that an AI-powered future specifically is "more advanced". For example, transitioning from fossil fuels to renewables is IMO a future that looks "good and fair for regular people". But building solar panels requires energy and water, placing them requires lots of land, building batteries requires mining lithium which is bad for the local environment, building hydro power destroys ecosystems, etc.
I imagine you don't oppose this because it's overall better for humans and the planet. I'm just making the point that there are nontrivial trade-offs, and building anything requires the use of resources such as land, water, and energy.
If we're in agreement so far, then I think the main thing we're in disagreement about is whether AI is actually worth the cost. ("What does this 'future' do for us besides take our jobs?")
And to this I'd ask, how should we handle such disagreements in a free society? I may think that Mr. Beast recreating Squid Game was a profligate waste of human and non-human capital, just to make a buck. Or more seriously, I'm a vegetarian. Worldwide, meat and dairy production accounts for (very roughly) 80% of agricultural land use [1], 30% of agriculture's water use [2], and 15% of total human GHG emissions [3]. I don't think the benefit is worth the extreme cost.
People disagree with me about Mr. Beast and beef, though. They think that these are worth the cost to land, water, energy, and the planet overall.
My question is, how should we resolve disagreements of this kind, where one person thinks another person's actions are spending resources in a way that is not worth the return? It seems much larger than AI.
The real problem is that there is so much money in politics now that the freedom of choice through elections is often an illusion. Money decides what we do with our planet and resources more than we do.
Sure, we agree on that. Everything has a cost. I’m a lifetime vegetarian also.
Just because “progress has a cost” doesn’t mean I have to support whatever the owner class decides is progress. They are explicitly telling us their plan for AI: to take our jobs. This isn’t speculation - the CEOs are literally saying this openly, and we should listen.
Sam Altman can’t just throw around the words “cure cancer” occasionally and expect us to not see what he’s doing. The unemployment issue? He used to say we would solve it with UBI, and recently said he no longer believes that will work, without providing an alternative. I guess we’re just on our own while he destroys our livelihoods now?
The future the hyperscalers want involves insane energy and water use. What do we gain out of this exchange? Right now it’s fun that Claude Code does our job for us, but if they pull off their plan we’re a few years away from massive concentration of power, mass unemployment, AI assisted warfare, unprecedented misinformation campaigns, etc.
I don’t think I’m crazy for questioning whether this is worth it.
Among other things, consider https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...
> The lack of verification is the exact reason why the lies continue
I think the evidence suggests they are not particularly constrained by reality? Recall "They're eating the cats and dogs."
reply