Live data from Hacker News

Reports of code's death are greatly exaggerated

stevekrouse.com

311–320 of 486 posts

Re: Reports of code's death are greatly exaggerated

#311

r0ml's third law states that: “Any distributed system based on exchanging data will be replaced by a system based on exchanging programs.” I believe the same pattern is inevitable for these higher level abstractions and interfaces to generate computer instructions. The language use must ultimately conform to a rigid syntax, and produce a deterministic result, a.k.a. "code". Source: https://www.youtube.com/watch?v=h5f…

> “Any distributed system based on exchanging data will be replaced by a system based on exchanging programs.”

So distributed systems tend to converge towards being more and more mystifying? Cf. the mythical mammoth:

> Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.

Re: Reports of code's death are greatly exaggerated

#312

Earlier quoted context omitted.

That’s factually untrue. I’m using models to work on frameworks with nearly zero preexisting examples to train on, doing things no one’s ever done with them, and I know this because I ecosystem around these young frameworks. Models can RTFM (and code) and do novel things, demonstrably so.

Yeah. I work with bleeding edge zig. If you just ask Claude to write you a working tcp server with the new Io api, it doesn’t have any idea what it’s doing and the code doesn’t compile. But if you give it some minimal code examples, point it to the recent blog posts about it, and paste in relevant points from std it does incredibly well and produce code that it has not been trained on.

It also needs a validation loop. Give it the compiler output and I bet it would fix that code even without examples/a blog post.

Re: Reports of code's death are greatly exaggerated

#313

Earlier quoted context omitted.

> Business problems are essentially neverending That feels overly optimistic. LLMs seems on track to automate out basically any "email job" or "spreadsheet job," in which case we'll be looking at higher unemployment numbers than the great depression for at least some period of time. Combine with increased automation... There are a LOT of people in the world and already a not insignificant portion can't find work desp…

Do you really think the billionaires are willing to have consumers so impoverished that they can’t continue to spend large sums of discretionary income buying the things that make the billionaires themselves richer?

Well what would each billionaire do? Give out money so that the poor can give some of it back?

You cannot just point at a system, say it’d be unsustainable and then assume nobody will let that happen.

Monarchies, lords, etc. have had much more reason to support their own countryfolk, yet many throughout history have not - has society changed enough that the billionaires have changed on this?

Re: Reports of code's death are greatly exaggerated

#314

Earlier quoted context omitted.

> 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]. Well, of course. Despite people applying the label of AI to them, LLMs don't have a shred of intelligence. That is inherent to how they work. They don't understand, only synthesize from the data they were trained on.

> don't have a shred of intelligence. ... They don't understand, only synthesize from the data they were trained on. Couldn't you say that about 99% of humans too?

How can you ever say that about humans? Human brain is not trained once on all the data and then you start using it, human brain is constantly training and rewiring in the real time while being used, there is quite a dramatic difference from how LLM transformers work. Human can form new abstractions from sparse experience which is the true conceptual reasoning which LLMs are struggling with

Re: Reports of code's death are greatly exaggerated

#315

A week ago there was an artical about Donald Knuth asking an ai to prove something then unproved and it found the proof. I suppose it is possible that the great Knuth didn't know how to find this existing truth - but there is a reason we all doubted it (including me when I mentioned it there) i have never written a c compiler yet I would bet money if you paid me to write one (it would take a few years at least) it wo…

You could probably do it in a few days, C is not that hard to compile

And a few seconds more to write a stub `stdio.h` that will allow to compile at least helloworld.

Writing a compiler that can compile the Linux kernel is a bit more involved.

Re: Reports of code's death are greatly exaggerated

#316

Earlier quoted context omitted.

To add, just keeping up in this industry was already a problem. I don't know of many professions[1] with such demands on time outside of a work day to keep your skills updated. It was perhaps an acceptable compromise when the market was hot and the salaries high. But I am hearing from more and more people who are just leaving the field entirely labeling it as "not worth it anymore". [1] Medicine may be one example of…

> I don't know of many professions[1] with such demands on time outside of a work day to keep your skills updated. This is an extremely miopic view (or maybe trolling). The vast majority of software developers never study, learn, or write any code outside of their work hours. In contrast, almost all professional have enormous, _legally-required_ upskilling, retraining, and professional competence maintenance. If you…

Sure, but those same professional certifications and development hours also allow them to not need to re-prove their basic competency when interviewing.

Re: Reports of code's death are greatly exaggerated

#318
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…

> We have a term for that already and it is called "comprehension debt". This isn't any different than the "person who wrote it already doesn't work here any more". > now requiring engineers to manually review AI changes [2] (which slows them down even with AI). What does this say about the "code review" process if people cant understand the things they didn't write? Maybe we have had the wrong hiring criteria. The "…

[dead]

Re: Reports of code's death are greatly exaggerated

#319
post #145

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…

> AI tends to accept conventional wisdom. Because of this, it struggles with genuine critical thinking and cannot independently advance the state of the art. Of course! But that's what makes them so powerful. In 99% of cases that's what you want - something that is conventional. The AI can come up with novel things if it has an agency, and can learn on its own (using e.g. RL). But we don't want that in most use cases…

Don't forget the line in the shape of a kitten!

Re: Reports of code's death are greatly exaggerated

#320

I’m writing a new type of CRDT that supports move/reorder/remove ops within a tree structure without tombstones. Claude Code is great at writing some of the code but it keeps adding tombstones back to my remove ops because “research requires tombstones for correctness”. This is true for a usual approach, but the whole reason I’m writing the CRDT is to avoid these tombstones! Anyway, a long story short, I did eventual…

Interesting. I'm the author of DocNode, a library that does exactly what you're describing; it might be useful. https://docukit.dev

Cheers!

Post reply on HN