Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reports of code's death are greatly exaggerated

stevekrouse.com

Post reply on HN
Print view View original

471–480 of 486 posts

Re: Reports of code's death are greatly exaggerated

#471

Post by vidarh »

glhaynes wrote: post #436
vidarh wrote: post #334

Earlier quoted context omitted.

Yeah, it's a bit like taking the output of a student project in a compiler construction class and using it to judge whether said student is capable of innovation without telling them in advance they'd be judged on that rather than on the stated requirements of the course.

It'd be interesting to prompt it to do the same job but try to be innovative. To your point, yeah, I mostly don't want AI to be innovative unless I'm asking for it to be. In fact, I spend much more time asking it "is that a conventional/idiomatic choice?" (usually when I'm working on a platform I'm not super experienced with) than I do saying "hey, be more innovative."

Yeah, I'd love to find time to. But e.g. I think that is also a "later stage". If you want to come up with novel optimizations, for example, it's better to start with a working but simple compiler, so it can focus on a single improvement. Trying to innovate on every aspect of a compiler from scratch is an easy way of getting yourself into a quagmire that it takes ages to get out of as a human as well.

E.g. the Claude compiler uses SSA because that is what it was directed to use, and that's fine. Following up by getting it to implement a set of the conventional optimizations, and then asking it to research novel alternatives to SSA that allows restarting the existing optimizations and additional optimisations and showing it can get better results or simpler code, for example, would be a really interesting test that might be possible to judge objectively enough (e.g. code complexity metrics vs. benchmarked performance), though validating correctness of the produced code gets a bit thorny (but the same approach of compiling major existing projects that have good test suite is a good start).

If I had unlimited tokens, this is a project I'd love to do. As it is, I need to prioritise my projects, as I can hit the most expensive Claude plans subscription limits every week with any of 5+ projects of mine...

Re: Reports of code's death are greatly exaggerated

#472

Post by vidarh »

thesz wrote: post #443
vidarh wrote: post #398

Earlier quoted context omitted.

There's no evidence to suggest a quantum computer exceeds the Turing computable.

The difference is quantum oracles can be constructed [1] and Turing oracle can't be [2]: "An oracle machine or o-machine is a Turing a-machine that pauses its computation at state "o" while, to complete its calculation, it "awaits the decision" of "the oracle"—an entity unspecified by Turing "apart from saying that it cannot be a machine" (Turing (1939)." [1] https://arxiv.org/abs/2303.14959 [2] https://en.wikipedia.…

This is meaningless. A Turing machine is defined in terms of state transitions. Between those state transitions, there is a pause in computation at any point where the operations takes time. Those pauses are just not part of the definition because they are irrelevant to the computational outcome.

And given we have no evidence that quantum oracles exceeds the Turing computable, all the evidence we have suggests that they are Turing machines.

Re: Reports of code's death are greatly exaggerated

#473

Post by vidarh »

jibal wrote: post #466
jibal wrote: post #397

Earlier quoted context omitted.

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…

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

I know very well what it means to be Turing complete. All the evidence so far, on the other hand suggests you don't.

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

An IO port is logically equivalent to infinite tape.

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

You can trivially execute every step in a Turing machine, hence you are Turing equivalent. It is clear you do not understand the subject at even a basic level.

Re: Reports of code's death are greatly exaggerated

#474

Post by Cthulhu_ »

lateforwork wrote: post #71

Chris Lattner, inventor of the Swift programming language recently took a look at a compiler entirely written by Claude AI. Lattner found nothing innovative in the code generated by AI [1]. And this is why humans will be needed to advance the state of the art. AI tends to accept conventional wisdom. Because of this, it struggles with genuine critical thinking and cannot independently advance the state of the art. AI…

I consider LLMs to be good at "more", not "better".

Coincidentally, most of my work is "more", most of the advancements are done during project setup.

Re: Reports of code's death are greatly exaggerated

#475

Post by yabutlivnWoods »

JSR_FDED wrote: post #259
yabutlivnWoods wrote: post #225

Earlier quoted context omitted.

The innovation isn't the output but the provenance. We don't necessarily need a Chris Lattner to make a compiler now. End of the day Chris Lattner is a single individual, not a magic being. A single individual posting submarine ads for his cleverness in the knowledge work subfield of language compilers. Of course he is going to drag the competition. Languages are abstraction over memory addresses to provide something…

So someone who is a proven expert in his field, who writes a detailed, well-reasoned, balanced assessment of the state of compiler development and the role LLMs play in this, is according to you, “A single individual posting submarine ads for his cleverness in the knowledge work subfield of language compilers. Of course he is going to drag the competition.”? Chris Lattner has forgotten more about language and compile…

What's that? Sorry. Busy working on chips that will unemploy Chris Lattner

I have forgotten more about chip and electrical engineering than he will ever know.

Re: Reports of code's death are greatly exaggerated

#476

Post by pylua »

elgertam wrote: post #345
pylua wrote: post #342

Earlier quoted context omitted.

Isn’t this what mcp is supposed to solve?

MCP connects the LLM to the APIs, which can be consulted with "tool calls." I'm talking about integrating the software I produce (with LLM assistance) to APIs. Traditionally, this is a nightmare given poor documentation. LLMs have helped me cut through the noise.

Right, I haven’t used it but thought at a high level it can do that integration on the fly.

I also do a lot of software system to system and in the long run I feel like ai will solve this.

Re: Reports of code's death are greatly exaggerated

#477

Post by andrekandre »

agentultra wrote: post #248
bluegatty wrote: post #232

Earlier quoted context omitted.

"The AI made a compiler, but it wasn't that novel, so AI is not novel" is a very poor rhetorical foundation Man - just think about what you said Two years ago that would have been beyond shocking. If 'AI is making compilers' - then that's 'beyond disruptive'. It's very true that AI has 'reversion to the mean' characteristics - kind of like everything in life .. ... but it's just unfair to imply that 'AI can't be crea…

The LLM didn’t make a compiler. It generated code that could plausibly implement one. Humans made the compilers it was trained on. It took many such examples and examples of other compilers and thousands of books and articles and blog posts to train the model. It took years of tweaking, fitting, aligning and other tricks to make the model respond to queries with better, more plausible output. It never made, invented,…

  > Writing React code is very tedious.
slightly off-topic perhaps, but it makes me wonder if its so tedious how did it catch on in the first place...

i feel like llms are abstracting away that tedium sometimes yes, but i feel its probably because the languages and frameworks we use aren't hitting the right abstractions and are too low level for what we are trying to do... idk just a thought

Re: Reports of code's death are greatly exaggerated

#478

Post by andrekandre »

rvz wrote: post #3

From "code" to "no-code" to "vibe coding" and back to "code". What you are seeing here is that many are attempting to take shortcuts to building production-grade maintainable software with AI and now realizing that they have built their software on terrible architecture only to throw it away, rewriting it with now no-one truly understanding the code or can explain it. We have a term for that already and it is called…

  > With the rise of over-reliance of agents, you will see "engineers" unable to explain technical decisions and will admit to having zero knowledge of what the agent has done.
i have seen this in real-time as we roll out this stuff; its not pretty and its aggravating as a code reviewer when asking "why is this here?" or "what does this part do?" and i cant get a straight answer except "i don't remember exactly"...

Re: Reports of code's death are greatly exaggerated

#479

Post by agentultra »

andrekandre wrote: post #477
agentultra wrote: post #248

Earlier quoted context omitted.

The LLM didn’t make a compiler. It generated code that could plausibly implement one. Humans made the compilers it was trained on. It took many such examples and examples of other compilers and thousands of books and articles and blog posts to train the model. It took years of tweaking, fitting, aligning and other tricks to make the model respond to queries with better, more plausible output. It never made, invented,…

> Writing React code is very tedious. slightly off-topic perhaps, but it makes me wonder if its so tedious how did it catch on in the first place... i feel like llms are abstracting away that tedium sometimes yes, but i feel its probably because the languages and frameworks we use aren't hitting the right abstractions and are too low level for what we are trying to do... idk just a thought

I wouldn’t call what LLMs are doing an abstraction. They generate code. You just don’t have to write it. It can feel like it’s hiding details behind a new, precise semantic layer… but you’ll find out once the project gets to a certain size that is not the case: the details absolutely matter and you’ll be untangling a large knot of code (or prompting the AI to fix it for the seventh time).

It’s a good thought and I tend to think that this is the way I would feel more productive: better languages that give us the ability to write better abstractions. Abstractions should provide us with new semantic layers that lose no precision and encapsulate lots of detail.

They shouldn’t require us to follow patterns in our code and religiously generate boilerplate and configuration. That’s indirection and slop. It’s wasted code, wasted effort, and is why I find frameworks like React to be… not pleasant to use. I would rather generate the code that adds a button. It should be a single expression but for many reasons, in React, it isn’t.

Re: Reports of code's death are greatly exaggerated

#480

Post by jibal »

jibal wrote: post #466
jibal wrote: post #397

Earlier quoted context omitted.

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…

> You can trivially execute every step in a Turing machine, hence you are Turing equivalent. It is clear you do not understand the subject at even a basic level.

LOL. Such projection. Humans are provably not Turing Complete because they are guaranteed to halt.

Post reply on HN