So, just in general, I've been seeing more and more foldable phones like this. How well are they holding up now? Having Apple use one seems to be at least somewhat of a vote of confidence that the tech has reached some level of acceptable maturity, so I assume "not trash", but I don't know how good that represents. I'm a compulsive fiddler so I'm not really in the market for a phone I can fiddle to death without even consciously realizing it, but I'm at least curious if the tech is reaching the point where one might expect a more normal user to casually expect them to last 2+ years with normal use.
You know, everyone's focused on the math and the human drama aspects, but to me the real story should be about this accusation that they somehow read the stream of data these guys were generating and then reacted to it at all on a human level is pure poison for their hopes for enterprises to be using their software.
Even if these two mathematicians were using the AI services under a clause that nominally allows OpenAI to train on their data, it is still another level above for there to exist some pathway within OpenAI to know that someone is doing something very valuable and important with their AI and to swoop in to try to steal the value of that work. It doesn't matter exactly what that pathway is, just that it exists is a big deal. Today it's a Millennium Prize, but tomorrow, is it the next hot new product category? Is it the patent someone is working on? Does OpenAI constitutionally believe that you may be using their product but whatever you produce really belongs to them and you are just borrowing it? Can we trust contracts that promise that they don't believe that if this is how they act?
Even people who are consciously aware that their sessions are being used to train the AI don't expect the AI companies to be in some way scanning the stream of what AI is working on for high-value propositions to snipe. That changes the relationship between these companies and enterprises, and anyone who thinks they may be doing this sort of work, deeply and fundamentally.
It isn't just that OpenAI is now something we should be suspicious about for math. It's all high-value science. Is there anyone trying to figure out how to develop a next-generation AI architecture using OpenAI? Better stop, OpenAI could see it and scoop you out of who knows how much value.
There is an old story attached to many historical figures that goes:
Churchill: Madam, would you sleep with me for a million pounds?
Woman: My goodness… well, I suppose I would.
Churchill: Would you sleep with me for a pound?
Woman: Certainly not! What kind of woman do you think I am?
Churchill: Madam, we’ve already established that. Now we are
just haggling over the price.
If this accusation is true, which I'm not completely confident about, but if it is true, that is the situation we would be in... we would have established that OpenAI is willing to steal from its customers, the only question is where the line is now, and where the line might be in the future.
Honestly the human drama, while the compelling story, is in monetary terms orders of magnitude less important than the question of whether OpenAI has a mechanism to steal ideas from its customers. Has this happened before and they just successfully covered it up? Or maybe the people stolen from thought it was innocent and just a coincidence that they were scooped? If it established that there is a price, I have a lot of questions about that price.
There's also the fact that you are in control. You are not obligated to take the AI's commits. I don't even let it commit much of the time because commit time is review time for me. If it changes the button blue and does four other things, you can just take the blue change and discard the rest. It can't stop you.
This isn't a defense of it doing those four other things. It would be nice if it did what you wanted correctly. I'm just saying, as long as our programming skills have not completely atrophied, we have the power.
“Ford carried on counting quietly. This is about the most aggressive thing you can do to a computer, the equivalent of going up to a human being and saying "Blood...blood...blood...blood...” ― Douglas Adams, The Hitchhiker's Guide to the Galaxy
This is the key to the problem that I think people are missing, possibly because they kind of want to miss it. Google and the other companies hiding behind LLMs and primarily doing it because they can't operate at the scale they do, with the dedicated ecosystems to gaming them that they develop, without this hiding. They can't afford humans to review in a minute or two what scammers can generate in fractions of a second, not even at their scale.
Now, I'm enough of a fan of decentralization and the destruction of these massive sites with way too much control to say that I'm perfectly comfortable saying that they should be mandated to handle these things more sensibly and with more humans. That such a plan would have the side effect of breaking them up into vastly, vastly smaller pieces, causing an technological Cambrian explosion of various sites and diversity resulting in the parasites no longer being able to focus all their firepower on a very small set of targets, is for me a bonus, if not the main goal. However, I, and anyone who agrees with me on this, is rather clearly in the minority.
In the meantime, if we're going to have things the size of Google or Facebook, there simply is no solution where we all get human review whenever we ask for it, because instantly every spammer and abuser will ask for the human review. There just isn't a solution. It looks like there is an obvious solution when you consider "how will Google review this one application" but that's not the landscape Google faces. They have to solve the problem of how to deal with the entire landscape of requests they face at once.
This gets rid of the scams but makes all surviving reviews unreliable since they'd all be pay-to-play. It'd be better to just remove reviews altogether at that point.
Which doesn't seem like such a bad idea now that I've said it out loud.
As I said to another comment, this isn't a place for architecture astronautics or squinting until one thing looks like another. It's all assembler under the hood in the end and that language not only doesn't have color, it doesn't have types in any practical sense of the term. At the level of Haskell itself, IO is a color and IO is not a function argument. The compiled code is all assembler. The Haskell may itself be an interpreter for a language that has no color. Above it there is no color, below it it may be implementing something without colors, but at the level of Haskell itself, IO is a color.
In Bluefin, IOE (which allows you to do I/O, i.e. what Haskell's IO also allows you to do) is an argument, and therefore not a color under your interpretation.
Your configuration structs are not "everything". You probably have dozens of things in them. You have hundreds to thousands of different parameters to different functions. By the time your configuration structs have hundreds of things in them you have thousands to tens of thousands of parameters to functions. Only a fairly small fraction of things make it all the way up to main.
This is exactly what I was talking about with this being a "cognitively available" operation. You notice when you have to propagate something all the way up to the top precisely because it is not something you do very often and it stands out as an exception when you do. If you are literally propagating everything up to main, all the time, every time you change any function anywhere in your program, you are doing something very, very wrong.
I think this is a case where you want to avoid architecture astronautics and deal with languages as they are presented. Yes, in the end it's all continuation passing, or depending on the cut of your jib, it's all just assembler in the end, but meanwhile, down in the trenches, there are real, practical differences in color that change how you program in those languages, and that's the topic color addresses.
I cited the case of an argument color already in the text for Zig... in fact, that's conditionally a color depending on what is passed, which is even more sophisticated then an argument merely being unconditionally a color.
What some people want to do is call every argument a "color", that is, I changed this function to have to take a Username and now it's Username-colored is the claim. I supposed I should have made that more clear. This provides a definition where that is not the case.
Pedantically, colored functions in Go might be ones that produce their output on a channel rather than returning a value. Then, you need select/for-range/<- to get their result, similar to “await”.
Practically, the runtime’s ability to suspend and move goroutines around means that the impact of that (niche/rarely appropriate as a default approach) kind of coloring is much less in Go than in other languages.
So, like, legit pro AI tip, at least for 3rd-quarter 2026... whenever you're working on something interesting, ask the AI about prior art, or to do a scan of the scientific literature. Whether it's economics, health, or something algorithmic at work, at least the AIs I've used (as we've not all spent all the time with all the models) are still generally inclined to give you exactly what you ask for. They may do a good job at giving you what you asked for, but they won't generally do a whole lot more. Ask them to go looking around and it's like giving them a 30 point IQ boost sometimes. They all operate way better when you fill the context window with relevant information then when you're operating just in the latent space of their training, but they only rarely seek it out without being prompted on their own.
On my near-term todo list is to explore a particular crank physics theory of my own with AI... but not as a way to validate it, I know it's a crank theory that is far too simple to have been missed by pros in the relevant fields, but as a window into the literature and figure out what's wrong with it and thereby learn something. I will be framing it to the AI in pretty much precisely that way: Go get literature and reputable sources and talk through why this is already well known, probably well known to be a bad and wrong idea.
I still feel like not enough people are talking about this here on HN... AI has opened the scientific literature like never before. It's like being able to interrogate it and interview it as if it was a person, rather than just searching papers, for keywords you don't know, for lines of thought you've never heard of, in a sub-sub-sub-field you didn't even know existed, and failing before you even knew what it is you wanted. I've read more papers in the past 6 months than the past 10 years. Whatever opportunity you have to try this out, be it some question bothering you for the last 10 years, or a crank theory of your own to prove out against the literature, the foundation of some vibe-coded program informed by the literature rather than just vibing on the neural weights directly, or just asking something random about the studied effects of beavers on local ecosystems, you gotta try this. Prompt it specifically for "reputable sources and scientific papers", that helps a lot. It does not make you suddenly an expert in the field, but it does let you poke through the pile of literature far, far more effectively than you could hope to before.
And then don't forget to ask it why your summary is wrong or incomplete. Even if it doesn't convince you, you'll learn yet more.
Yup, I too am surprised this hasn't (at least by my awareness) entered the zeitgeist.
At work I'm putting together an MCP server that more easily exposes our legume data for model consumption, and part of the insane value-add has been the curatorial work that our collaborators at USDA put into the data over years. For example, genome data (i.e. nucleic acid fastas) include relevant metadata such as their DOIs, so models can fetch and read the original papers (if they're open access, of course).
This goes a long way to boosting the intelligence/usefulness of these systems for research.
Yes, exactly. Researchers will not like the fact that I refer to the literature as merely a manual, but “RTFM” applies here. Someone has likely already investigated what you’re looking at, or at least found a way to not do it. And sure it’s in the weights, but if you put papers directly in front of the LLM it’s much more impactful.
As someone with a scientific background, and the word scientist in my title I guess this comes as a “no duh” to me. Prior art is table stakes. There should be nothing more embarrassing to a researcher than learning that they’ve failed to read and consider other work on a topic that’s easily accessible.
> why this is already well known, probably well known to be a bad and wrong idea.
This is still pointing the LLM in a specific direction . You might want to prompt something like “give me a summary of relevant literature” and avoid sharing your point of view. Wdyt?
It's to compensate for the effect where they are still a bit of a yes man. Way, way better than they were several models ago where they were pathological about it, but still a bit biased in the direction of explaining why you're right. I know I'm not right. I don't want a neutral summary, I want an interesting discussion of what's wrong with my idea and why.
If I were operating in a field in which I was already an expert, or in a field that is more strongly opinion-based anyhow (e.g., philosophy... it isn't particularly clear that being an "expert" in philosophy has any strong impact on your chances of being "right", for whatever that even means in that field), I might ask for something more neutral, but I know I'm not.
Honestly, having watched people argue about what simple is for about the last 10 years, I've pretty much settled on it not being a well-defined term. We know complex when we see it for sure, at least when it is present in quantity, but simplicity is not just the absense of complexity. There's at least three concepts we're all trying to stuff into the same word, and they are not only not "orthogonal" they are often in conflict with each other. I don't even think it can be rehabilitated, it can only really be abandoned, to clear the way to trying to characterize the multiple concepts we're trying to stuff into this one word.
It is especially dangerous when something is "good" and people try to appropriate the term to appropriate the goodness of the term, as if goodness flows from a term to the thing it is attached to rather than the other way around. "Simple" is good so my good thing must be "simple" to be "good". But it doesn't. Simple can even be bad, in the wrong place or in the wrong sort of "simple" for a given job.
Reducing entropy or cross entropy fits intuition and theory and it's what LLMs target during training in order to model languages, to model the world and to enable calibrated reasoning across uncertainty and gray areas. I think you can use entropy reduction as a good definition of simplicity even though it's not always "simple" to understand what that entails.
"Few tokens" - perhaps the most literal simplicity, literally, it doesn't use many tokens to do the job. But as the article points out, that doesn't necessarily fit with...
"Easy to reuse" - This is that simplicity that functional programming aspires to, where you craft some precise abstraction that somehow captures something like "monad". Haskell is full of this sort of simplicity, oozing out of every pore, but people generally think of it as a very complex and hard langauge, contrasting...
"Easy to understand" - As in, not cognitively complex. It is amazing how quickly things that I would otherwise describe as very simple still blow out our little minds. Consider the first time you saw quicksort... or even how it feels now. It's not a lot of tokens, but it's twisty and recursive and especially if you're not mathematically trained and in practice it's easy to call it more "complicated" than a CRUD form that takes in and validates 10 parameters in a straightforward way, even though in terms of what is actually happening the CRUD form may be doing vastly more than the little quicksort algorithm. It just isn't being twisty, recursive, and subtle in how it does it.
And I'm just filling out the first three that come to mind. Note these are not always in conflict by any means... but they certainly aren't always in harmony with each other either.
(One might argue "easy to reuse" is more about the complexity of the code doing the reusing, but I feel like this is definitely something people mean when they talk about the simplicity of code.)
reply