this post was submitted on 09 Feb 2025
5 points (77.8% liked)
Programming
264 readers
2 users here now
Welcome to the Lemmygrad programming community! This is a space where programmers of all levels can discuss programming, ask for help with problems, and share their personal programming projects with others.
Rules
- Respect all users, regardless of their level of knowledge in programming. We're here to learn and help each other improve.
- Keep posts relevant to programming and related topics.
- Respect people's personal preferences. If you disagree with someone's choice of programming language, method of formatting code, or anything else, don't attack the poster. Genuine criticism is fine, but personal attacks are not.
- In order to promote breaks from typing, all code snippets must be photos of code written on paper.
Just kidding :), please use proper markdown code blocks.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Defining specifications IS programming. We are well pass the age in which we write specs first, Assembly later. Now most programming languages focus primary on high level business logic. These are called "high-level programming languages".
The question then becomes "Can LLMs become even higher level programming languages?". I think the answer to that question would be "no". LLMs have the ability to mix existing code examples into new code, these code are not guaranteed to work, so they need human intervention to make it right. And it must be "human" specifically because LLMs have not the intrinsic understanding of the code and therefore would often stuck in a loop (of emitting the same code back and forth).
I have also tried them before, LLMs are good at well-documented problems, well-documented frameworks, and well-documented programming languages. Let them solve niche problems, and you would spend all day tweaking prompts to get it to give the right answer, at which point, why not simply write the code yourself? LLMs also fail with big enough codebases.
Sure it is programming, but it's a different style of programming. Modern high level languages are still primarily focused on the actual implementation details of the code, they're not really declarative in nature.
Meanwhile, as I wrote in my original comment, the LLM could use a gradient descent type approach to converge on a solution. For example, if you define a signature for what the API looks like as a constraint it, can keep iterating on the code to get there. In fact, you don't even need LLMs to do this. For example, Barliman is a constraints solver that does program synthesis this way. It's also smart enough to reuse functions it already implemented to build more complex ones. It's possible that these kinds of approaches could be combined with LLMs in the future, where LLM could generate an initial solution, and a solver can refine it.
Finally, the fact that LLMs fail at some tasks today does not mean that these kinds of tasks are fundamentally intractable. The pattern has been that progress is happening at a very quick pace right now, and we don't know what the plateau will be. I've been playing around with DeepSeek R1 for code generation, and a lot of the time what it outputs is clean and correct code that requires little or no modification. It's light years ahead of anything I've tried even a year ago. I expect it's only going to get better going forward.
Barliman is interesting. What if I write
f(0) = 2, f(1) = 3, f(2) = 5? Would it be smart enough to generate a functioning prime number lookup function (nevermind efficiency)?Given enough constraints sure, it's basically just logic programming at its core.