[vatsachak]

Math is way more automatable than programming.

In math, a proof is a proof. We don't know if we can get there and so getting there is the hard part.

In software, we always know that we can solve the problem. So HOW to solve the problem is the hard part. Because the type of solution involves maintainability, which involves planning, LLMs suck at it. This leads to "LLM slop code" whereby the LLM creates ad-hoc convoluted logic with redundancies and no reuse of existing standard library batteries.

Unless you're a Grothendieck who gets mad at Deligne for not solving the Weil's conjecture "THE RIGHT WAY", software is fundamentally different than math in this respect.

So I'll say it again, AI will win a fields medal for before managing a McDonald's simply because there are enough big problems within arms reach than their current capacity to plan over time

[nicf]

I've spent some time working both as a math researcher and as a software engineer, and I think this comment actually underrates the similarity between the two fields as they're actually practiced.

Some math research does involve grabbing a single, fully specified conjecture off the shelf and hunting for a proof of it, and it's true that if you manage to solve a long-standing open problem, other mathematicians will be interested no matter how you did it.

But this isn't all of what they do, probably not even most of what they do. Like in software engineering, it's not always obvious which question would be the most useful one to ask. A lot of mathematical work also goes into what we call "theory-building", where you could say that primary work goes into coming up with definitions rather than theorems. Mathematicians also care a great deal about how something is proved; a lot of them are some of the most aesthetically picky people I've ever met. Words like "ugly", "beautiful", "creative", and "boring" are used to describe both definitions and proofs all the time.

From the outside, it can look like all they're doing is pumping out proofs at any cost. But I promise you that when I talk to mathematicians who don't have any experience building software, they have a similarly narrow view of that field as well! Both fields, from the inside, look a lot more human than you might expect.

[vatsachak]

I think that your take is quite optimistic. Having published in top tier journals my only experience is that mathematicians care about what other mathematicians worked on and failed to solve. Theory building papers are dime a dozen and don't get published in high tier journals unless they solve a problem.

Math is such that most theories are built after solving a problem and actually don't solve a larger class of problems. Etale Cohomology is an example of a rare exception. Grothendieck was mad that Deligne used adhoc complex analysis techniques to prove Weil. But everyone else was thrilled.

Whereas in CS, a good theory (library) solves a large class of problems. The reason being is that CS tackles general problems while math specific ones. Math on average solves problems that don't lead to solutions to other problems.

To me at least, math is more of a game like chess and coding is more of an art. There are aspects which are a game, like performance engineering but I'm pretty sure that LLMs will become superhuman at that soon

[nicf]

If your complaint is about the type of work that gets you published in a fancy math journal, then I'll happily join you on the barricades. Sure, getting a paper into Annals of Mathematics or whatever is more game than art in the sense I think you mean here.

But "what mathematicians care about" is much, much broader than what gets you published in a fancy journal. Mathematics as a human activity is millennia old, much older than the concept of journals or even universities, and that activity is, to me, very beautiful, worth preserving, and more of an art than a game. The incentive structure of academia for the past few decades has done a pretty bad job at preserving that art form, but that doesn't mean mathematicians as actual human beings don't care about it --- if they didn't, they probably would have chosen a different career.

[vatsachak]

Very fair. But when you say "What mathematicians care about", you are taking about mathematicians today, who really care mostly about politics

[rocqua]

It seems to me you hooked onto the wrong part of proofs vs software compared to what OP meant. The difference OP cares about isn’t how much one cares about style. Instead the important difference lies in validation. A proof can be validated as either correct or wrong. That type of hard feedback really helps combat the optimism and desire for shortcuts of modern models.

Now, that still doesn’t help an LLM distinguish between good and bad correct proofs. But it still really helps a lot. On top of that, taste in proofs is a lot more uniform than taste in coding. That helps LLMs be better at judging the quality of a proof, because there’s less disagreement in the wider world.

[sigbottle]

The standards of proof are different from the fundamental operation of "OK, cool, you solved this problem. Why does this problem matter? Isn't it useless? Senseless? Meaningless?" You have this same question whether or not you're in an a priori discipline (mathematics), scientific fields proper, or engineering. "Absolute certainty" has nothing to do with it. I can assure you, people on the job are not looking for The Absolute Truth when doing their jobs, yet they still can question at a solution by asking: are we solving the right problem?

(Although in general, there's no true difference between "I answered the question correctly, but the question was mapped to this thing we call 'reality' wrong", and "I answered the question incorrectly", because you can (try) adding the constraints that you really wanted targeted in case A, to case B, and boom, suddenly a question/answer pair that was "Answered correctly, but question doesn't map to reality" now becomes, "You answered this question wrong". However, individuals generally tend to have some breakpoint to differentiate between the two).

[rocqua]

That's a valuable extra distinction between Mathematics and Software.

In Mathematics there is much more clarity on what question you want to answer. It's much less likely you get an answer to a question, and then realize that the question was useless. Whereas in software its almost guaranteed that your first implementation, correct or otherwise, will solve the wrong problem.

[sigbottle]

Really? Not my experience at all.

If you're saying that math has a consolidating network effect, sure. There are a lot of people who think similar problems are important. I guarantee you that when math was small, that is not the case, and when coming up with new math, that's not the case, and when coming up with sub problems to tackle large problems, that is not the case.

[nicf]

No, what I'm saying is that I don't agree that taste in mathematics is more uniform than taste in coding! Mathematicians argue about taste all the time. Just as you might look at a piece of code and agree that it compiles and doesn't have any fatal bugs but still think it's badly written, hard to follow, hard to modify, or whatever else, mathematicians judge mathematical work using very similar criteria.

[vatsachak]

Maybe a subset of mathematicians, but if someone proved that RH was undecidable we would still give them the millennium prize.

[pishpash]

The types who do ugly proofs, when they write code, produce spaghetti code. It's the same thought process going into how to approach something.

[fsmv]

I think the difference is in math the problem is fully specified and easily verifiable and in programming it's not. I don't agree that we always know we can solve the problem.

[vatsachak]

Not always, sure but 90% of the time yes.

For example, create a DFA for a regex, not too bad just use Thompson's algorithm and then NFA->DFA. But now we have to care about efficiency, user API, maintainability of definitions etc.

Coding is more of a human problem than math

[sashank_1509]

> So I'll say it again, AI will win a fields medal for before managing a McDonald's simply because there are enough big problems within arms reach than their current capacity to plan over time

AI can manage a McDonald’s already. If manage means directing humans to do something to ensure the store is running. If manage means running robots, then yes maybe that is 5 years away but just directing humans to run a store, that is possible right now.

[vatsachak]

No it can't. Show me a business which uses in context learning to manage a McDonald's

[wanderlust123]

Well that’s a problem of incentives. Why would a manager outsource their own job to an AI?

[vatsachak]

It's not a problem of incentives. Every executive wants to inject LLMs everywhere these days. If they haven't somewhere it means that it does not work.

[wanderlust123]

Every executive wants to inject LLMs downstream from their own job. As you get away from execution and toward management the incentive to innovate gets less and less as management at the same level.

[fsmv]

Have you not seen vend bench?