> There's nothing that AI won't be able to mine and accomplish (aside from being literally human), it's only a matter of hardware and scale at this point.
Sure there is: problems that require knowledge that simply doesn't exist yet. Until "AI" turns into general purpose robots that can develop new tools to explore the world, it is, in fact, pretty damned limited in what it can do without human help. The world is vast. Math is small.
Biology is replete with examples. Computers "solve" protein folding [1], and midwits immediately leap to conclusions that drug development will also quickly fall. But we literally have no idea how most of biology works, and simply getting to the starting line for drug development problems is often 95% of the battle. Come talk to me when you've done a million experiments to find the fundamental knowledge that unlocks the pathway(s) we didn't know about that makes a drug discovery program possible in the first place [2].
I am not pessimistic about humans running out of challenges. We'll just declare one class of problems "done" [3], and move on to the next frontier, as we always have. The problem with AI doomers is that they lack imagination that extends beyond computers, or perhaps more accurately, are so sophomoric in their thinking that they skip over the hard parts of any problem they don't fully understand. This stuff reminds me of the endless smartypants whinging about the end of human intelligence when chess machines started beating grandmasters. Chess was never really that great a measurement of human intellectual capacity, and we found new things to do with our big monkey brains.
[1] They did not solve protein folding, except in the minds of people who don't fully understand the problem.
[2] ...and invented new machinery to make the experiments possible in the first place.
> problems that require knowledge that simply doesn't exist yet.
Obtaining the knowledge is a process of trial and error, bruteforce, observation, search, etc. Humans follow that same process. Machines can do that too. If they discover or are taught the same heuristics humans use, and a computational capacity greater than that of all humans combined, they will outpace us in this endeavour.
> Until "AI" turns into general purpose robots that can develop new tools to explore the world, it is, in fact, pretty damned limited in what it can do without human help.
For sure, but this isn't a question of if, but when. LLMs are already rapidly accelerating the pace of every scientific field, so advancements in technology will start to compound.
> Biology is replete with examples. Computers "solve" protein folding [1], and midwits immediately leap to conclusions that drug development will also quickly fall. But we literally have no idea how most of biology works, and simply getting to the starting line for drug development problems is often 95% of the battle. Come talk to me when you've done a million experiments to find the fundamental knowledge that unlocks the pathway(s) we didn't know about that makes a drug discovery program possible in the first place [2].
I don't disagree with you. The amount of complexity in biology is incredible and due to its unpredictable squishy and noisy nature and the advanced machinery needed to analyze it with precision at the microscopic scale, vast amounts of data accumulation are still required to discover the useful patterns here, and the search space will be enormous. Still, it will be done. Here is some recent movement in that direction: https://www.anthropic.com/news/model-hardware-standard-resea...
> I am not pessimistic about humans running out of challenges. We'll just declare one class of problems "done" [3], and move on to the next frontier, as we always have.
This is fair, you're probably right about that. I think they'll be challenges for the AI to solve though, not humans as a collective. Hopefully we have something to contribute to that process, other than just expressing our desires.
> The problem with AI doomers is that they lack imagination that extends beyond computers, or perhaps more accurately, are so sophomoric in their thinking that they skip over the hard parts of any problem they don't fully understand. This stuff reminds me of the endless smartypants whinging about the end of human intelligence when chess machines started beating grandmasters. Chess was never really that great a measurement of human intellectual capacity, and we found new things to do with our big monkey brains.
I'm not an AI doomer, I despise the AI doomer movement and the incessant fearmongering, it's incredibly unhealthy and its only purpose is to perpetuate panic in the aim of maintaining and establishing power, and preventing others from obtaining power that threatens the status quo. What cultish idealogical humans will do with this technology if they're left unchecked with staggering power and no one to stop them is certainly a big concern though.
> Obtaining the knowledge is a process of trial and error, bruteforce, observation, search, etc. Humans follow that same process. Machines can do that too. If they discover or are taught the same heuristics humans use, and a computational capacity greater than that of all humans combined, they will outpace us in this endeavour.
Sure, you can reduce the 99.9% of research labor that matters to "a process of trial and error, bruteforce, observation, search, etc.", but that's like saying that nuclear fusion is only a few technical details away from implementation. We already know the theory!
The part where you're closest to being correct is "trial and error" -- it would be great if a robot existed that could do any experiment, tirelessly, with the mechanical fidelity, intelligence and creativity of a human. That robot does not exist. Moreover, the fundamental techniques to do the kinds of observation necessary to unlock the parts of science we don't know about do not exist. They must be invented. So now we have two problems. The problems are recursive and interlocking.
Biology and chemistry are the sciences I know best, so I will use those examples -- every major breakthrough of the last 50 years has involved invention of some fundamental new mode of observation, such as crystallography, NMR, mass spec, electron microscopy, various kinds of light microscopy, DNA sequencing, PCR, etc. Someone invents some innovative technique, and a wave of progress happens. Expert practitioners in in the lab are probably the second rate-limiting step, but the part that LLMs can do -- taking data and turning it into hypotheses -- is the part that carries the least value. Any postdoc has enough ideas to keep a lab going forever.
The thing you linked about Anthropic creating a "robot standard" for operation of lab tools is great for Anthropic, but that's about all. There's tons of lab automation tooling already. Having LLMs run the microscope is maybe a cool automation technique if you have the kinds of experiments that benefit from it, but those are rare, and they're still ultimately limited by people doing the upstream work.
AI will certainly help people be more efficient at their current scientific jobs, make better methodology more universal, etc., but suggesting that it will replace actual scientists is just science fiction.
> Biology and chemistry are the sciences I know best, so I will use those examples -- every major breakthrough of the last 50 years has involved invention of some fundamental new mode of observation, such as crystallography, NMR, mass spec, electron microscopy, various kinds of light microscopy, DNA sequencing, PCR, etc. Someone invents some innovative technique, and a wave of progress happens. Expert practitioners in in the lab are probably the second rate-limiting step, but the part that LLMs can do -- taking data and turning it into hypotheses -- is the part that carries the least value. Any postdoc has enough ideas to keep a lab going forever.
Technology is not made in a vacuum though, it is a process of incremental advancements, often in parallel, over multiple industries. If LLMs are watching the worlds scientific and hardware progress on all fronts and compute is dedicated to exploring combinations of new ideas and ranking them on estimated practicality toward outstanding problems or current goals that humans have, I see no reason why they won't be able to come up with creative new technology. The issue with cutting edge technology is that it's expensive and time consuming to validate. If AI can develop sufficient simulations, it could be validated digitally.
Surely you don't believe that this isn't around the corner, given the scale we are now seeing? For example dedicating 80,000 agents over 88 hours to write a proof for Navier-Stokes.
Maybe this isn't a wildly creative exercise or you consider math "small" in comparison, but I think it's quite clear to see that this isn't a question of whether it's possible but rather a question of how long it will take to get there.
There's no shortage of talent being dedicated to this pursuit, either. For example: https://finance.yahoo.com/technology/ai/articles/deepmind-ch... - The company aims to accelerate scientific and engineering breakthroughs by building autonomous systems that handle entire research cycles.
Only if you interpret statements as being binary logic.
"seem to be" carries semantic meaning here: I'm stating my interpretation of the situation based on data we have available (which is limited) and my prior.
Put another way: "We can't say that for sure, but my money is on it not being a simple case of intellectual property theft"
Imagine if they broke it down to each distinct source, that'd be several billion cases of copyright infringement (though it's going to be determined by what courts think and that often comes down to "who can afford the best lawyers" in practice if not intent).
Apparently if I use lib-gen, that's copyright infringement and I'm exposed to legal risk but it seems fine to download all of it if your intent is "train an AI" so far.
Other people are allowed to have their priors, too. Even under a non-informative prior, the weight of the evidence (Tristan's account, OpenAI's announcement, and Bubeck's "denial", if you want to call it that, plus multiple other mathematicians coming forward with similar experiences) pushes the probability mass toward some degree of impropriety.
What exact evidence are you incorporating into your prior to come out with this posterior?
We are giving you an opportunity to correct yourself. You are instead trying to make your nonsensical statement make sense. Not only does the first part of your sentence literally contradict the second part:
> We don't have enough accurate knowledge to say [one way or the other], and it doesn't seem to be the case at all [based on our incomplete knowledge].
But it is in no way equivalent to this:
> We can't say that for sure, but my money is on it not being a simple case of intellectual property theft
No. They don't. Every day I see huge numbers of people in lace up oxfords, high heels, and more. And no, people don't ruin their expensive shoes by crushing the heel cups. People do that for cheap shoes, sure, and professionals often wear slip on / slip off shoes intentionally, but it's by no means generalizable.
That's largely because a lot of developers have made the devil's bargain of replacing standard web stuff with badly re-implemented JS versions of same. People did it because they could, but never considered if they should.
See most of the ecosystem around React, for reference. It's idiotic that things like URL management are done in Javascript. Or form controls. I guarantee that if we stopped doing this kind of stuff, JIT wouldn't matter.
To some extent this is just saying "developers will depend upon the performance given to them", and that's true, but it's also true that as soon as things like V8 and Node appeared, JS became ubiquitous. Pandora's container, if you will.
> See most of the ecosystem around React, for reference.
I've never used React myself, but what I've heard about it makes me question my own sanity. So are you going to tell me that instead of just updating the DOM tree directly I'm going to apply the changes to my data, then pass the entire model to the framework, which would then diff it with the previous version to get the changes back out, it would then call my functions that return components, and it would then diff the virtual DOM to find out what changed, and only then would it update the actual page? Why the fuck would anyone ever want that? What's so hard about simply changing the innerText or inserting elements or whatever?
Oh and now Google and Apple are insisting that this is the way to do UIs in native apps as well, with Compose and SwiftUI respectively.
The way the front end developer community seems to largely encourage learning top-down isn't helping either. I'll forever remember that one guy we made a small project with. He learned React but had no clue what "send a request" and "pass a parameter" means, and I had to explain him how to use XHR.
The DOM is the slowest part of the browser. It's not Javascript, it's the DOM. React is an attempt to manage the slowness of the DOM. One seemingly small change to a page (like setting innerText) can have many ripple effects with reflow on mamy parts of a page.
With thousands of DOM elements on a page, the DOM becomes a bottleneck. This isn't the fault of front-end developers, and it's not really the fault of browser developers. HTML/CSS/JS is a very powerful system, but it's also complex and can cost a lot of compute. When you understand this, then the reasons for React and other front-end frameworks become easier to accept.
> One seemingly small change to a page (like setting innerText) can have many ripple effects with reflow on mamy parts of a page.
I haven't looked into how browsers actually do it, but my mental model for it is that if something changes, this merely sets a flag on that element or its parent that its layout is not valid any more. Then, on next vsync, all the elements that have this flag set have their layout recalculated, potentially going up the tree as necessary. The only exception is if your script tries to get any layout-related property, e.g. offsetWidth. Then, as if as part of the getter of such a property, the layout recalculation will run immediately.
That is to say, if you need to make a lot of changes to the DOM, you should make them within one JS invocation so only one layout pass happens sometime after you're done.
OP here. The steel-man argument for React is not that it is faster at rendering. It cannot be, because it ultimately relies on the same DOM that everyone else does to do the job, and it has to set up a massive JS data structure to do what it does, which uses a lot of memory and has big GC costs. Arguments that assert that the React virtual DOM are faster than the native/shadow DOM are simply wrong [1]. Even the React team admits this [2] (though back in the day, they made a number of puffed-up claims about speed that never made sense).
The principle argument in favor of React today are developer ergonomics. People don't have to manually alter individual elements anymore -- they just describe state, and React takes care of the UI change set. On top of that, you have components, etc., that are debatably more pleasant to work with, and at the least create an ecosystem advantage for users of the framework. One can certainly see the argument for something like facebook, where there are probably dozens of different things changing independently at any given time.
But that said, one really has to question whether React makes sense anymore, given LLMs. Back when the alternative was that someone had to bespoke code every UI component, it might have been worth taking the hit of having to adopt the entire React ecosystem. But now that LLMs are writing the code, there's really no argument for developer ergonomics, and suddenly, things like "rewriting URL handling in JS" are pure liabilities.
[1] Though sadly, many front-end devs don't know this.
Well, I'm an old-school guy. I'm all for developer ergonomics, as long as they don't affect the runtime. I use PostCSS and TypeScript in my own projects precisely for this reason, because they both make things more convenient for me yet leave no trace in the finished product that the users see.
> But now that LLMs are writing the code
Hopefully that's a temporary state of affairs and everyone will eventually go back to writing code by hand. I've never even considered using an LLM to get my job done, the whole idea is as alien to me as are these types of UI frameworks. To me, the best language to describe what you want from a computer isn't English, it's a programming language.
>But now that LLMs are writing the code, there's really no argument for developer ergonomics, and suddenly, things like "rewriting URL handling in JS" are pure liabilities.
The popular coding AIs go down all the time. Last week all of them were down at the same time. If there's a bug causing losses of thousands or millions of dollars per minute, do we really want to let the LLM write incomprehensible code?
You may not need react. If you want to make the smallest possible change to the dom to reduce latency, then make the smallest possible change to the dom. Choose solidjs. (Not a sponsored post).
> Why the fuck would anyone ever want that? What's so hard about simply changing the innerText or inserting elements or whatever?
It's so that you have the page reflecting your data at all times.
The browsers should have been written this way, instead of having byzantine update functions with all forms and a pair of *Text to rule them all. But creating it in Javascript is a really bad idea.
The problem is not url management. That should happen just once or twice during the life cycle of a page. If it takes 0.1ms or 1ms doesn't have any impact on the usability.
One of my problems was that I wanted to show data in the browser. It is a convenient delivery platform, after all. However, Chrome (and Chrome in particular) has tremendous trouble displaying large pages. A 400x400 table takes a long time to render. I could solve that in JavaScript. I had to, really.
So, as practically always, the problems stem from a combination of factors, and bad programming definitely is one of them.
That's largely because a lot of developers have made the devil's bargain of replacing standard hardware and OS primitives with badly re-implemented C versions of same. People did it because they could, but never considered if they should.
See most of the ecosystem around modern systems software, for reference. It's idiotic that things like memory layout and bit-level hardware management are done in C abstractions. I guarantee that if we stopped doing this kind of stuff, compiler optimizations wouldn't matter.
To some extent this is just saying "developers will depend upon the performance given to them", and that's true, but it's also true that as soon as things like compilers and standard libraries appeared, C became ubiquitous. Pandora's container, if you will.
> It's idiotic that things like memory layout and bit-level hardware management are done in C abstractions. I guarantee that if we stopped doing this kind of stuff, compiler optimizations wouldn't matter.
Cute, but no, not even close to a good metaphor. The C example is abstracting away fundamental complexity in a new platform. The other is completely re-writing -- in duplicate and slightly broken -- what the platform gives you for free. There's nothing about implementing form controls or URL management in JS that is more abstract. It's just different; a downstream bad decision that branches off a long tree of other bad decisions.
The equivalent level of idiocy in a C-related metaphor would be...I dunno...if you decided that you didn't like the way that header files worked, and decided to keep the C compiler, but build an external header-file management system in Fortran [1] that calls the C compiler for you. Or even closer to the JS metaphor, you shipped a special C compiler that had an embedded interpreted language that only activated at compile time, and you then used that language to allow any user to fundamentally change the syntax of C.
(It hopefully shouldn't be lost on you that this exact approach to language features has been repeatedly tried in the javascript world, including right now, with package management. But see also: typescript, coffeescript before that, Dart, etc. Javascript is a mess, and history repeats itself with regularity about every 5 years.)
[1] ...and then you re-write that about sixty times, each time being slightly incompatible with the last, and all having different fundamental incompatibilities with C headers.
Plenty of software/tools that we use are as good as they are despite being run by entitled pricks.
Some would even argue that in certain cases (apple being the biggest example I can think of from the past at least with Jobs) they are as good as they are almost due to the megalomaniacal people who run them.
This isn't responsive to the parent's question, in a way that ironically underscores the point: you can tell me that "1 in 50 patients experience X", but that's meaningless, unless I know what X is in the selected population at baseline.
I don't mean to pick on you. This problem is widespread in academic research.
It's not that simple. Untold numbers of U.S. bonds are held by people running the "carry trade" (borrowing JPY at low interest rates in order to buy mostly U.S. treasuries and make money on the difference).
If you raise JPY rates, then these U.S. treasuries are going to get liquidated driving up U.S. rates and of course the U.S. doesn't like that.
So, I believe the US is pressuring Japan NOT to raise rates, i.e. to save the U.S.'s own currency.
This is undoubtedly why Bessent bought $5 to $10 billion JPY using Euro awhile back (as rumored, the exact amount is a secret). That way he could try and bailout Japan and by using Euro instead of USD, not affect US inflation so much. He also did it without telling anyone in Europe which quite pissed them off as well.
It's really funny seeing these shenanigans take place with all the pompousness the US shows regarding its currency and how it pretends it itself is not going broke.
It’s true that the carry trade unwinding suddenly would be…traumatic (and debatably the root cause of the rate spike that killed SVB a few years ago), but it could be managed gradually, and must be done to bring Japan back from the brink.
> So, I believe the US is pressuring Japan NOT to raise rates, i.e. to save the U.S.'s own currency.
The US is pressuring the BoJ not to liquidate US debt to get the USD needed to buy Yen. It only tangentially relates to bond yields, and has nothing to do with defending the USD.
It would be better for the US if Japan just normalized rates, but Japanese politicians are resistant.
The carry trade hides a lot of US debt, too. Why would the US only care about the US debt held sovereignly by Japan and not by the banks and hedgefunds executing the carry trade?
If the US is not trying to defend the US dollar, why'd they use Euros and not USD to prop up the Yen, and also why surprise everybody doing so?
And, if it is better for the US if Japan normalized rates, then why did the US buy yen at all? According to you, just telling Japan to raise rates would be better, right?
The carry trade does not hide public US debt. The US Treasury is concerned about Japan because it’s like the first or second largest holder of Treasuries in the world.
> If the US is not trying to defend the US dollar, why'd they use Euros and not USD to prop up the Yen
Because that was the legal facility open to them. They used a foreign currency reserve that they had the ability to trade.
> And, if it is better for the US if Japan normalized rates, then why did the US buy yen at all? According to you, just telling Japan to raise rates would be better, right?
Yes. Go re-read my comment: Japanese politicians do not want rates to go up. It’s like a cornerstone of current LDP policy.
> The carry trade does not hide public US debt. The US Treasury is concerned about Japan because it’s like the first or second largest holder of Treasuries in the world.
I never wrote it hides the debt, it borrows JPY at a low interest rate and then buys U.S. treasuries at a higher interest rate, making money on the difference.
> Because that was the legal facility open to them. They used a foreign currency reserve that they had the ability to trade.
Again, why not use U.S. Dollars? And again, why not at least give a heads up to the Europeans? You are not directly addressing my questions.
> Yes. Go re-read my comment: Japanese politicians do not want rates to go up. It’s like a cornerstone of current LDP policy.
No, you re-read my comment that you just slapped into your response and then completely ignored. WHY DID THE US BUY YEN AT ALL? You are ignoring my point and just restating your conclusion.
More detail on the Patrick Boyle video where the actual picture of Bessent's note that included that purchase is mentioned. Also the fact that these are specifically French bonds that were dumped with no warning. This is dropping the mask of Western solidarity I think Xi is over the moon
It’s pointless. Setting money on fire
to avoid the inevitable.
Since Bessent did what he did the whole issue has been swallowed up in the idiotic partisan maw of US politics, but it’s just a self-defeating effort by Japan to fight the market.
They can't afford to. At 4.5% average rates, their interest payments will consume something on the order of 80% of their government budget and huge portions of GDP. Their 30 year paper was trading at 4.1% last week. If the short end of the yield curve pumps even higher, they are utterly screwed. Consequences of 250% debt to gdp.
Well, hopefully they’ve been smarter than the US about managing bond duration, but yeah. Doesn’t change reality in the currency markets, and sometimes you have to choose between the devil and the deep blue sea.
The US has the same problem. Maybe less extreme, but the balance sheet has tons of short-term debt, and rates aren’t cooperating.
Yes, but it’s not uniform at all. The paper shows cooling in some parts of the north, and heating in the southern latitudes, along with significant variations by depth.
There’s a lot of nuance in this stuff - far more than global average surface temperature (which is primarily good for scary headlines) and “fish don’t have AC”.
Yes. But there's a clear difference between, say, stealing someone's voice, identity or intellectual property, and preventing someone from using automation to do labor.
The former is obviously unfair to the person whose identity is stolen. The latter is sour grapes from people who want to control the future.
I also can't bring myself to get incensed over someone using a robot to write code. It's literally the modern equivalent of smashing knitting looms.
You keep framing it as getting incensed over other people using ai to write code; but that isn't what it's about. A dev union would not attempt that; it would attempt to ensure quality of life for your class of people (and their families) as much as possible. It isn't about policing entire industries or other entities; it is about DEFENDING those who they would, do, and always have exploited when binding contracts or legislation don't prevent them from doing so.
Union = a group of people defending their rights and that includes the right to a life that isn't at the utter mercy of perpetual enshittification due to the infinite mechanical plodding of heartless (by definition) megacorporations that would never hesitate to eradicate peoples' livelihoods and treat humans as material for the orphan grinder if they could get away with it.
> it would attempt to ensure quality of life for your class of people (and their families) as much as possible.
What is “your class of people”, and why is it threatened by what other people do with coding robots?
You can try to dress it up as an intellectual argument, but at root it’s the same thing that the luddites were trying to do: defending your preferred lifestyle from technological advances.
We, the ditch diggers of the world, support your unqualified resistance to the use of steam shovels! Fewer holes, slower!
Your argument boils down to the idea that human life is not worth defending, even when capital actively undermines it by undercutting honest people's honest efforts to work for a living.
Thank you for outing yourself as a low-empathy, capital-aligned individual who makes bad-faith arguments, I'll know not to engage you from now on.
> Additionally Ebola (Zaire) has previously been shown to be potentially spread via aerosols.
…between inoculated pigs and monkeys, in a lab. Pigs infected with this strain, quite notably, do not become hemorrhagic, and as the article notes, manifest as a respiratory illness. So it isn’t fair to point at it and draw conclusions about humans.
Moreover, from the article:
”We have also never observed transmission of EBOV from infected to naive macaques, including in an experiment employing the same cage setting as in the current study, where three NHPs intramuscularly inoculated with EBOV did not transmit the virus to one naive NHP for 28 days, the duration of the protocol.”
They’re literally telling you that the thing you’re fear-mongering about was tested for, and not found to exist.
> the CDC and associated institutions resolutely claim this is not possible, yet also insist on full respirator PPE.
…for people working with late stage infections, in close quarters. Usually with many such cases. This is a case where “better safe than sorry” applies.
Sure there is: problems that require knowledge that simply doesn't exist yet. Until "AI" turns into general purpose robots that can develop new tools to explore the world, it is, in fact, pretty damned limited in what it can do without human help. The world is vast. Math is small.
Biology is replete with examples. Computers "solve" protein folding [1], and midwits immediately leap to conclusions that drug development will also quickly fall. But we literally have no idea how most of biology works, and simply getting to the starting line for drug development problems is often 95% of the battle. Come talk to me when you've done a million experiments to find the fundamental knowledge that unlocks the pathway(s) we didn't know about that makes a drug discovery program possible in the first place [2].
I am not pessimistic about humans running out of challenges. We'll just declare one class of problems "done" [3], and move on to the next frontier, as we always have. The problem with AI doomers is that they lack imagination that extends beyond computers, or perhaps more accurately, are so sophomoric in their thinking that they skip over the hard parts of any problem they don't fully understand. This stuff reminds me of the endless smartypants whinging about the end of human intelligence when chess machines started beating grandmasters. Chess was never really that great a measurement of human intellectual capacity, and we found new things to do with our big monkey brains.
[1] They did not solve protein folding, except in the minds of people who don't fully understand the problem.
[2] ...and invented new machinery to make the experiments possible in the first place.
[3] ...and we'll likely be wrong about that.
reply