This is pretty funny to see, because every financial firm interview process I've seen involves some variant of solving a bunch of stuff with min heaps.
Never before has a set of engineers been more primed to solve a problem
> many have voiced other structures such as altering prices based on time/place/road driven, which would require more data than simple odometer readings.
There are people who won't care about this but I think that legibility would be a huge concern here. It's one thing to do $X per megameter, but it's another to start breaking it down into various zones etc
At that point might as well just do congestion pricing in cities.
By living off grid they are stress testing things so that when things are tougher (perhaps temporarily!) things have a higher chance of chugging along
And obviously, like, they go to places and talk to people and buy equipment etc.
There’s a whole gamut of failure modes for tech from “total civilizational collapse” down to “cell tower is down”, and time periods from “forever” down to “a couple of days”
People doing this sort of lifestyle but sharing findings and ideas and ultimately maybe pointing out how more can be done with less is part of us building up knowledge together isn’t it?
These people aren’t completely offline even! They blog and post online!
The problem is that one a person writes a 60 page proof in theory that person has spent an inordinate amount of time on the proof and can answer questions, describe some insight, etc etc.
If a random person is given a 60 page proof to digest and not the author, those hidden insights that _aren't_ in the paper might be completely inaccessible. Maybe the AI will "just" be able to provide the insights. Maybe. But pedagogy is tricky work, and despite these AIs being able to do all this fancy math we can't get them to write good cover letters yet, so....
Ultimately we might be left with just a bunch of intellectually unsatisfying proofs. This means way less drive to simplify the proofs or rework them.
End result: we generate a layer of "less efficient" mathematics, that won't get built upon. We will not actually have any shoulders upon which to stand.
According to Scott Aaronsson, OpenAI set their agents on 8000 different problems, and got 372 final proofs. Even spending twice the original effort on simplifying and reworking those proofs so that they do not "feel like something written by someone who’s on psychedelics" would only increase the compute by less than 10% (assuming all the agents had a similar token budget).
The fact that they did not do so can only mean that either (1) their agents currently lack the capability to do it, or (2) OpenAI are completely indifferent and do not care in the slightest if the proofs are understood or not.
> The fact that they did not do so can only mean that either (1) their agents currently lack the capability to do it, or (2) OpenAI are completely indifferent and do not care in the slightest if the proofs are understood or not.
Come now, this is kind of unreasonable. When you're working on a new technology, you first get the ugly, inconvenient-to-use prototypes functioning with the core new thing you need; then you work on packaging it up into a format useable in production. I'm sure the very first digital camera sensors weren't very useful for photographers either; but it isn't really even possible to build the rest of the technology required to turn raw output of a digital sensor into something a professional photographer can use until you have the raw output itself.
The research is still on going on the raw output; getting things to the next stage, where the results are widely useable by professional mathematicians (and then on to engineers and scientists to whom the results would be practically useful), is a whole new research area.
Seems like you are just subscribing to the first option I gave, "their agents currently lack the capability to do it", but saying you think they will be more capable in the future if they can move away from the inconvenient-to-use prototypes after more research. Thinking it might be possible in the future is not in disagreement with anything I said, so I am not sure what you thought was unreasonable about my description.
Imagine someone looking at digital camera researchers showcasing a ground-breaking new sensor, and reacting by saying "Well obviously they're completely indifferent and do not care in the slightest if their work is used by real photographers or not."
Like, "Orr... maybe they care a lot, but haven't gotten to that part yet?"
You are conflating the two options with each other (lack of capability vs indifference). One of them is true, not necessarily both ("or", not "and"). I did not claim a lack of capability was the same as indifference.
They claim each result used three hours of compute on average. Even spending significantly more on simplifying and reworking would delay the release with a single day at most. If avoiding such a minor delay took precedence over (2), I think "indifference" is the correct term. It has also been a while since the release now, so there is ample opportunity to post follow ups if time pressure was the only concern.
Why do that when they can spend more hours extending QRH to a proof of the full Riemann Hypothesis? The opportunity cost of digging up small potatoes is the whole enchilada.
But why should process of discovering mathematical insights be any less attainable to AI models?
The concern is being raised without evidence, because the evidence points to the gap simply being frontier models have just started to be able to get a raw proof out. Why, given existing progress, should we expect them to be unable to distill insights from those proofs?
Certainly this even more likely doesn't matter at all for applications: if I can send a radio signal further because my AIs design it a certain way, that's an unambiguous result. Which is really the next step here: turn a proof into a "mechanical" application.
From launch until 2007, the PSP was capped at 222MHz. After firmware 3.50, the full 333MHz was unlocked. The GoW games were released after this, so I assume they used the full 333MHz.
I've had discussions around this with theorem prover types (OPLSS, highly recommend for people who can take the two weeks off)
The sort of head canon for any of the automated proof systems is that lean saying a proof is correct is "if lean is correct then the proof is correct".
One can get the temptation to try and prove lean correctness with lean but I believe _that_ is impossible due to the incompleteness theory.
_But_ the discussions I had, everyone was kind of in agreement with the idea that you could continue to shrink down the "kernel" of lean with lean (or whatever proof system really) so that in the end the thing you have to trust is pretty small.
I think lean can verify it implements its own rules, but not that its own rules are sound (you can't prove a contradiction). If you are just prepared to trust that the rules are sound, then you would be able to trust leans implementation (if you had that Lean proof that it implements its own rules)
I don't know if we can really be clear about the order of things, but I think even without AI maths is filled with "someone provides a proof of X, and the proof itself is wrong/incomplete but X itself is true".
"Incomplete" proofs might be a way of viewing this. You have a NL argument to prove X. It turns out the NL proof has holes you can drive a truck through. So... you go around and patch the holes.
The resulting proof is different! You can start off with a bad proof and find a correct proof. Sometimes.
EDIT: for French speakers (maybe autodub gets you there) I saw a very nice simple case of this recently. A commonly stated proof for a relatively simple theory. The proof has a giant hole in it, and completing it requires some work [0])
I've always believed the opposite: get conditionals deep in your code so that the higher level control flow is regular.
But I suppose my greater philosophy for making code that avoids bugs is that you have a couple things that are done when dealing with data:
- distribution
- deciding
And you want to avoid distribution and deciding being mixed together in the same spot.
"Distribution" can be for loops but also breaking up some data based on some key into N bistinct buckets
"Deciding" is where you're looking at the data more closely to make some decision (like "is this a big customer or a small customer")
Distribution often involves decision making, but if you mix them all in one spot you can obfuscate your decision points. Splitting it up just makes things "obviously" right or "obviously" wrong. Perf stuff is another discussion of course, but in practice most things are not at a scale where it matters.
by_category = defaultdict(list)
for d in data:
by_category[category(d)].append(d)
for category, per_category_data in by_category.items():
do_thing(category, per_category_data)
I really value code patterns that make mistakes obvious, or at least makes it harder to stuff a mistake in somewhere. Some patterns are harder to describe in this model though.
(I do like the advice of having a consistent vocabulary for working on collections as a principle though, I just find that top-level conditional use tends to quickly get you into "... why is this method not called" territory, which is a more annoying problem than "why is this slow")
Your category() function contains the branch. So you pushed the condition up, and later loop through each bucket with its corresponding function. So you pushed the loops down. This is typical data oriented programming.
That's another good way to look at it - sometimes the "base" is more like a physics substrate. Physics doesn't care about semantics, it just is. Putting semantics first would be weird.
If the data don't need to be processed in batches by category, and if the category is derivable from an data item alone, I don't really see the benefit you're proposing.
Even worse, by splitting one state (and one derivable category from that state) into two separate arguments for do_thing, something can be off rather badly. I'd then feel the need to design an assertion of the relation of the arguments in order to make things bearable again:
def do_thing(category, data):
# to avoid shadowing lets rename your function `category` to `category_from_item`
assert all(category == category_from_item(item) for item in data)
...
But that would add a third loop to your two loops, and would duplicate the computation of a category.
Instead, if category would be a property of data item:
class DataItem:
@property
def category(self):
...
...and the do_thing function would work on a single data item, then it'd just become a simple matter of one for loop and one match/case:
def do_thing(item):
match item.category:
case ...:
...
For a server using a DB, all of your methods are calling out to data stores. So you're like "OK I receive a &connection" but all the mutability is hidden inside.
There's a bunch of type direction you can do to get around this (`ReadConnection` vs `ReadWriteConnection` and some other magic), far from an immediate win but it's not impossible.
People talk about mutability a lot but the vast majority of Python code I see in the wild is SSA and has _very_ little mutability to begin with.
Of course ownership still has its costs. Lots of "I guess I'm copying this dict because I don't know if the owner will modify it or not" issues.
I think people overestimate how much they'll get from `&mut` annotations on business logic, and undersestimate how much line noise they'd get from a lot of the other stuff that happens in a lot of business logic.
Granted, I'm coming from a web-dev/Django perspective, where duck typing and overriding methods in subclasses is used heavily. And a lot of that doesn't have a nice 1:1 equivalent in the Rust model.
(I enjoy Rust BTW, just don't feel particular excitement about shuffling around strings in it)
not everyone is writing simple web servers :) and if you are, then the rust is easy to read as it's simple. I also use django in some large projects, and don't see a future of my use of django really anymore. If I'm not feeling like rust is a great fit, I usually reach for Java with javalin.
I feel like everyone already knew the code was the easy part, even pre-AI.
> Coding being so easy now has just pulled back the curtain and shown the world that software developers really don't have much left to contribute. It's been done, a thousandfold.
Maybe, but I feel like there's a reason that the "useful" AI-generated work all seems to come from people who could get to the same result given "infinite" time anyways.
AI tool usage reflects and amplifies your own skill sets IMO, and I think it's pretty hard to be amazing at software architecture design but be bad at coding.
> I feel like everyone already knew the code was the easy part, even pre-AI.
I don’t agree with this at all. There still tons of buggy software around, and we ship multi-gigabyte electron installs that make fanspeeds go high and are way less efficient than software written 20 years ago.
Also the largest problem of AI written code is that is so hard to maintain, so no, coding is not the easy part.
I think it is the other way round. Building requirements from many sources of data and view points is the easy part. Implementing great, maintainable systems out of them needs specialists.
I agree there's a bunch of buggy software, my contention is that a lot of that exists is because people are bad at the hard part and the easy part!
I am also dissatisfied at the current state of software so feel your pain. I think it's just that like .... I think if you can't get the code right you're probably not getting the requirements etc right either.
Never before has a set of engineers been more primed to solve a problem
reply