Live data from Hacker News

Reports of code's death are greatly exaggerated

stevekrouse.com

461–470 of 486 posts

Re: Reports of code's death are greatly exaggerated

#461
post #459
post #381

Earlier quoted context omitted.

In theory a computer should be able to model any physical process so I do agree it's only a matter of time. That said I don't think I will be alive to see it honestly. The current tech won't get us there just like the steam engine or the internal combustion engine didn't get us to the Moon. And getting to AGI is probably more like getting to Mars.

> In theory a computer should be able to model any physical process Wait, which theory is that? In church turing theory the computer can compute any computable function. Why do we think that the computer can model any physical process? Or are we suggesting that you can build a computer out of whatever physical process you want to model?

> > In theory a computer should be able to model any physical process

> Wait, which theory is that?

The Church-Turing-Deutsch Principle. (Which isn’t a theory in the empirical sense, but somewhat more speculative.)

> Or are we suggesting that you can build a computer out of whatever physical process you want to model?

Well, you obviously can do that. Whether that computer is Turing equivalent, more limited, or potentially a hypercomputer is...well, Church-Turing-Deutsch says the last is always false, but good luck proving it.

Re: Reports of code's death are greatly exaggerated

#462
post #347
post #190

Earlier quoted context omitted.

Church turing is about computable functions. Uncomputable functions exist. For example how much rain is going to be in the rain gauge after a storm is uncomputable. You can hook up a sensor to perform some action when the rain gets so high. This rain algorithm is outside of anything church turing has to say. There are many other natural processes that are outside the realm of was is computable. People are bathed in t…

That example is completely false: how much rain will fall is absolutely a computable function, just a very difficult and expensive function to evaluate with absurdly large boundary conditions. This is in the same sense that while it is technically correct to describe all physically instantiated computer programs, and by extension all AI, as being in the set of "things which are just Markov chains", it comes with a ma…

The busy beaver function isn't uncomputable.

You just compute the brains of a bunch of immortal mathematics. At which point it's "very difficult and expensive function to evaluate with absurdly large boundary conditions."

Re: Reports of code's death are greatly exaggerated

#463

Earlier quoted context omitted.

You have to be incredibly incompetent and naiive to look at the absolute garbage theatre that AI outputs today to go "yeah this will write all future code". Usually the response, for the last years, has been "no no you don't get it, it'll get so much better" and then they make the context window slightly larger and make it run python code to do math. What will really happen is that you and people like you will let Cl…

Can you explain what you think will happen, actually? People at OpenAi and Anthropic aren’t longer coding by hand. Are you saying everyone changes their mind and goes back? Not gonna happen. You have to work around this new constrain.

Yes, I'm saying that the companies who's entire business model is selling you AIs are not a reliable source. And of course, again, if you are competent, you can see that AI only generates passable outputs when guided or when the scope is small. This guiding only works when there is a human operator.

You're all being fooled by emergent behavior, which acts like intelligence, but really doesn't fool people who are familiar with how to write code.

I'm sorry, I'm not sure how to say this without sounding elitist, but the goal post has not moved since GPT 3. These tools, autonomously, produce code that only fools the clueless. I don't know how else to put it and I'm getting really tired of this argument that "look, company with billions and some of the buggiest shittest software is using AI to write it". No shit they are.

So what's going to happen? We will see the same divide we've seen with JavaScript. It's new, then everyone says it's what everyone must use. C++ developers no longer needed--its all JS now. No need for native UIs, it's all JS now. If you're not learning the latest web tech, you'll miss out and fall behind. If you're studying for anything but web, you'll be out of a job in 5 years. And now, a couple decades later, we are still waiting for it.

Re: Reports of code's death are greatly exaggerated

#464

Earlier quoted context omitted.

I've had to slowly and painfully learn the lesson that early on in a company's lifycycle it doesn't really matter how terrible the code is as long as it mostly works. There are of course exceptions like critical medical applications and rocket/missile guidance systems but as a general rule code quality is only a problem when it inevitably bites you much farther down the line, usually when customers start jumping ship…

> There are of course exceptions like critical medical applications and rocket/missile guidance systems but as a general rule code quality is only a problem when it inevitably bites you much farther down the line, usually when customers start jumping ship when it's obvious you can't scale or reach uptime contact targets. My experience is it hits both new-feature velocity and stability (or the balance between those tw…

There are phases in a company's lifecycle which carries different weights associated with code quality depending on factors like the domain, how many customers you have, what your risk aversion is etc. I'm just saying don't build a cathedral when a mole hill will do. If the product doesn't work that's another story, it still needs to stand up without falling over when you look at it sideways and having only juniors would be a good way to get the latter. Use basic design principles, and proven architectures but don't sweat things like code coverage, reinventing wheels because you think you can do it better than something you can just grab off the shelf rn. It'll inevitably be a bit of a hodgepodge in the beginning but that's ok. Consider early code as "throwaway", don't spend your limited time rewriting anything already working "better" unless you actually have the leisure to do so (few actually do, and even fewer realize they don't)

Re: Reports of code's death are greatly exaggerated

#466
post #397
post #333

Earlier quoted context omitted.

No, but unless you find evidence to suggest we exceed the Turing computable, Turing completeness is sufficient to show that such systems are not precluded from creativity or intelligence.

That's an irrelevant strawman. It tells us nothing about how create such a system ... how to pluck it out of the infinity of TMs. It's like saying that bridges are necessarily built from atoms and adhere to the laws of physics--that's of no help to engineers trying to build a bridge. And there's also the other side of the GP's point--Turing completeness not necessary for creativity--not by a long shot. (In fact, huma…

P.S. everything in the response is wrong ... this person has no idea what it means to be Turing complete.

> all we need to be able to do is to read and write a tape or simulation of one

An infinite tape. And to be Turing complete we must "simulate" that tape--the tape head is not Turing complete, the whole UTM is.

> A system that is not even Turing complete is extremely limited.

PDAs are not "extremely limited", and we are more limited than PDAs because of our very finite nature.

Re: Reports of code's death are greatly exaggerated

#467
post #197

Earlier quoted context omitted.

Feel free to ask Claude about any other contradictory request. I use Claude Code and it often asks clarifying questions when it is unsure how to implement something, or or autocorrects my request if something I am asking for is wrong (like a typo in a filename). Of course sometimes it misunderstands; then you have to be more specific and/or divide the work into smaller pieces. Try it if you haven't.

I have. In fact, I've been building my own coding agent for 2 years at this point (i.e. before claude code existed). So it's fair to say I get the point you're making and have said all the same stuff to others. But this experience has taught me that LLMs, in their current form, will always have gaps: it's in the nature of the tech. Every time a new model comes out, even the latest opus versions, while they are always…

The big flagship AI models aren't just LLMs anymore, though. They are also trained with RL to respond better to user requests. Reading a lot of text is just one technique they employ to build the model of the world.

I think there are three different types of gaps, each with different remedies:

1. A definition problem - if I say "airplane", who do I mean? Probably something like jumbo jet or Cesna, less likely SR-71. This is something that we can never perfectly agree on, and AI will always will be limited to the best definition available to it. And if there is not enough training data or agreed definition for a particular (specialized) term, AI can just get this wrong (a nice example is the "Vihart" concept from above, which got mixed up with the "Seven red lines" sketch). So this is always going to be painful to get corrected, because it depends on each individual concept, regardless of the machine learning technology used. Frame problem is related to this, question of what hidden assumptions I am having when saying something.

2. The limits of reasoning with neural networks. What is really happening IMHO is that the AI models can learn rules of "informal" logical reasoning, by observing humans doing it. Informal logic learned through observation will always have logical gaps, simply because logical lapses occur in the training data. We could probably formalize this logic by defining some nice set of modal and fuzzy operators, however no one has been able to put it together yet. Then most, if not all, reasoning problems would reduce to solving a constraint problem; and even if we manage to quantize those and convert to SAT, it would still be NP-complete and as such potentially require large amounts of computation. AI models, even when they reason (and apply learned logical rules) don't do that large amount of computation in a formal way. So there are two tradeoffs - one is that AIs learned these rules informally and so they have gaps, and the other is that it is desirable in practice to time limit what amount of reasoning the AI will give to a given problem, which will lead to incomplete logical calculations. This gap is potentially fixable, by using more formal logic (and it's what happens when you run the AI program through tests, type checking, etc.), with the mentioned tradeoffs.

3. Going back to the "AI as an error-correcting code" analogy, if the input you give to AI (for example, a fragment of logical reasoning) is too much noisy (or contradictory), then it will just not respond as you expect it to (for example, it will correct the reasoning fragment in a way you didn't expect it to). This is similar to when an error-correcting code is faced with an input that is too noisy and outside its ability to correct it - it will just choose a different word as the correction. In AI models, this is compounded by the fact that nobody really understands the manifold of points that AI considers to be correct ideas (these are the code words in the error-correcting code analogy). In any case, this is again an unsolvable gap, AI will never be a magical mind reader, although it can be potentially fixed by AI having more context of what problem are you really trying to solve (the downside is this will be more intrusive to your life).

I think these things, especially point 2, will improve over time. They already have improved to the point that AI is very much usable in practice, and can be a huge time saver.

Re: Reports of code's death are greatly exaggerated

#468
post #91

Earlier quoted context omitted.

> ...generate answers near the center of existing thought. This is right in the Wikipedia's article on universal approximation theorem [1]. [1] https://en.wikipedia.org/wiki/Universal_approximation_theore... "n the field of machine learning, the universal approximation theorems (UATs) state that neural networks with a certain structure can, in principle, approximate any continuous function to any desired degree of ac…

It has been proven that recurrent neural networks are Turing complete [0]. So for every computable function, there is a neural network that computes it. That doesn't say anything about size or efficiency, but in principle this allows neural networks to simulate a wide range of intelligent and creative behavior, including the kind of extrapolation you're talking about. [0] https://www.sciencedirect.com/science/article…

No, the size of those networks that would be capable of that are infeasible. That's a common fallacy. You hint at this but then dismiss it.

Mathematically possible != actually possible.

Re: Reports of code's death are greatly exaggerated

#469
post #462
post #347

Earlier quoted context omitted.

That example is completely false: how much rain will fall is absolutely a computable function, just a very difficult and expensive function to evaluate with absurdly large boundary conditions. This is in the same sense that while it is technically correct to describe all physically instantiated computer programs, and by extension all AI, as being in the set of "things which are just Markov chains", it comes with a ma…

The busy beaver function isn't uncomputable. You just compute the brains of a bunch of immortal mathematics. At which point it's "very difficult and expensive function to evaluate with absurdly large boundary conditions."

> The busy beaver function isn't uncomputable.

False.

To quote:

  One of the most consequential aspects of the busy beaver game is that, if it were possible to compute the functions Σ(n) and S(n) for all n, then this would resolve all mathematical conjectures which can be encoded in the form "does ⟨this Turing machine⟩ halt".[5] For example, there is a 27-state Turing machine that checks Goldbach's conjecture for each number and halts on a counterexample; if this machine did not halt after running for S(27) steps, then it must run forever, resolving the conjecture.[5][7] Many other problems, including the Riemann hypothesis (744 states) and the consistency of ZF set theory (745 states[8][9]), can be expressed in a similar form, where at most a countably infinite number of cases need to be checked.[5]
"Uncomputable" has a very specific meaning, and the busy beaver function is one of those things, it is not merely "hard".

> You just compute the brains of a bunch of immortal mathematics. At which point it's "very difficult and expensive function to evaluate with absurdly large boundary conditions."

Humans are not magic, humans cannot solve it either, just as they cannot magically solve the halting problem for all inputs.

Re: Reports of code's death are greatly exaggerated

#470

Earlier quoted context omitted.

Also: if that one particular AI-produced compiler has nothing innovative, that only means that the human "director" behind the AI didn't ask it to produce anything innovative; what it does not mean is that AI can never produce anything innovative in a compiler.

> if that one particular AI-produced compiler has nothing innovative, that only means that the human "director" behind the AI didn't ask it to produce anything innovative Couldn't it also be true that the AI didn't produce innovative output even though the human asked it to produce something innovative? Otherwise you're saying an AI always produces innovative output, if it is asked to produce something innovative. An…

> Couldn't it also be true that the AI didn't produce innovative output even though the human asked it to produce something innovative?

It could have been, but unless said human in this case was lying, there is no indication that they did. In fact, what they have said is that they steered it towards including things that makes for a very conventional compiler architecture at this point, such as telling it to use SSA.

> Otherwise you're saying an AI always produces innovative output

They did not say that. They suggested that the AI output closely matches what the human asks for.

> And I don't think that is a perfection that AI has achieved.

I won't answer for the person you replied to, but while I think AI can innovate, I would still 100% agree with this. It is of course by no means perfect at it. Arguably often not even good.

> Sometimes AI can't even produce correct output even when non-innovative output is requested.

Sometimes humans can't either. And that is true for innovation as well.

But on this subject, let me add that one of my first chats with GPT 5.1, I think it was, I asked it a question on parallelised parsing. That in itself is not entirely new, but it came up with a particular scheme for paralellised (GPU friendly) parsing and compiler transformations I have not found in the literature (I wouldn't call myself an expert, but I have kept tabs on the field for ~30 years). I might have missed something, so I intend to do further literature search. It's also not clear how practical it is, but it is interesting enough that when I have time, I'll set up a harness to let it explore it further and write it up, as irrespective of whether it'd be applicable for a production compiler, the ideas are fascinating.

Post reply on HN