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

C –> Java != Java –> LLM

observationalhazard.com

Post reply on HN
Print view View original

11–20 of 50 posts

Re: C –> Java != Java –> LLM

#11

Post by seanmcdirmid »

cadamsdotcom wrote: post #3

The spec rarely has enough detail to deterministically create a product, so current vibecoding is a lottery. So we generate one or many changesets (in series or in parallel) then iterate on one. We force the “chosen one” to be the one true codification of the spec + the other stuff we didn’t write down anywhere. Call it luck driven development. But there’s another way. If we keep starting fresh from the spec, but kee…

> The spec rarely has enough detail to deterministically create a product, so current vibecoding is a lottery.

How is that different from how it worked without LLMs? The only difference is that we can now get a failing product faster and iterate.

> If we keep starting fresh from the spec, but keep adding detail after detail, regenerating from scratch each time..

This sounds like the worst way to use AI. LLMs can work existing code, whether it was generated by an LLM or written by human. It can even work on code that has been edited by a human, there is no good reason to not be iterative when using an LLM to develop code, and plenty of good reasons to be iterative.

Re: C –> Java != Java –> LLM

#12

Post by 8organicbits »

handoflixue wrote: post #7
chuckledog wrote: post #6

> “As an aside, I think there may be an increased reason to use dynamic interpreted languages for the intermediate product. I think it will likely become mainstream in future LLM programming systems to make live changes to a running interpreted program based on prompts.” Curious whether the author is envisioning changing configuration of running code on the fly (which shouldn’t require an interpreted language)? Or wh…

I think at some point in the future, you'll be able to reconfigure programs just by talking to your LLM-OS: Want the System Clock to show seconds? Just ask your OS to make the change. Need a calculator app that can do derivatives? Just ask your OS to add that feature. "Configuration" implies a preset, limited number of choices; dynamic languages allow you to rewrite the entire application in real time.

Maybe I'm missing it, but when my calculator app gets a new derivatives feature, how am I supposed to check that it's implemented correctly? End user one-shot of bug free code seems like a different technology than what LLMs offer.

Re: C –> Java != Java –> LLM

#13

Post by Muromec »

Vegenoid wrote: post #10
tjr wrote: post #5

Earlier quoted context omitted.

At that level of detail, how far removed are we from “programming”?

Without understanding the level of detail required, which we do not yet know, we cannot say. When I think of English specifications that (generally) aim to be very precise, I think of laws. Laws do not read like plain, common language, because plain common language is bad at being specific. Interpreting and creating laws requires an education on par with that required of an engineer, often greater.

Laws being unreadable is largely an Enlish-language problem zo. I have no problem reading them in my native language. Not requiring massive context size of case law makes things easier still. Big part of being a lawyer is having the same context with all the other lawyers and knowing what was already decided and what possible new interpretation is likely to be accepted by everyone else.

Re: C –> Java != Java –> LLM

#14

Post by seanw444 »

8organicbits wrote: post #12
handoflixue wrote: post #7

Earlier quoted context omitted.

I think at some point in the future, you'll be able to reconfigure programs just by talking to your LLM-OS: Want the System Clock to show seconds? Just ask your OS to make the change. Need a calculator app that can do derivatives? Just ask your OS to add that feature. "Configuration" implies a preset, limited number of choices; dynamic languages allow you to rewrite the entire application in real time.

Maybe I'm missing it, but when my calculator app gets a new derivatives feature, how am I supposed to check that it's implemented correctly? End user one-shot of bug free code seems like a different technology than what LLMs offer.

Yeah I don't see how LLMs are ever supposed to be reliable enough for this, but they did say "at some point in the future", which leaves room for another (better) technology.

Re: C –> Java != Java –> LLM

#16

Post by emodendroket »

cadamsdotcom wrote: post #3

The spec rarely has enough detail to deterministically create a product, so current vibecoding is a lottery. So we generate one or many changesets (in series or in parallel) then iterate on one. We force the “chosen one” to be the one true codification of the spec + the other stuff we didn’t write down anywhere. Call it luck driven development. But there’s another way. If we keep starting fresh from the spec, but kee…

Well, it’s really a return to the old-fashioned role of an analyst coming up with a data dictionary and a detailed spec. But in practice how often did that work as intended?

Re: C –> Java != Java –> LLM

#17

Post by dizlexic »

seanmcdirmid wrote: post #11
cadamsdotcom wrote: post #3

The spec rarely has enough detail to deterministically create a product, so current vibecoding is a lottery. So we generate one or many changesets (in series or in parallel) then iterate on one. We force the “chosen one” to be the one true codification of the spec + the other stuff we didn’t write down anywhere. Call it luck driven development. But there’s another way. If we keep starting fresh from the spec, but kee…

> The spec rarely has enough detail to deterministically create a product, so current vibecoding is a lottery. How is that different from how it worked without LLMs? The only difference is that we can now get a failing product faster and iterate. > If we keep starting fresh from the spec, but keep adding detail after detail, regenerating from scratch each time.. This sounds like the worst way to use AI. LLMs can work…

>How is that different from how it worked without LLMs?

I won't lie and say "That's a great idea" when it isn't.

Re: C –> Java != Java –> LLM

#18

Post by cess11 »

"Many have compared the advancements in LLMs for software development to the improvements in abstraction that came with better programming languages."

Where can I see examples of this?

Re: C –> Java != Java –> LLM

#19

Post by savolai »

chuckledog wrote: post #6

> “As an aside, I think there may be an increased reason to use dynamic interpreted languages for the intermediate product. I think it will likely become mainstream in future LLM programming systems to make live changes to a running interpreted program based on prompts.” Curious whether the author is envisioning changing configuration of running code on the fly (which shouldn’t require an interpreted language)? Or wh…

Smalltalk, mumps?

Re: C –> Java != Java –> LLM

#20

Post by Vegenoid »

Muromec wrote: post #13
Vegenoid wrote: post #10

Earlier quoted context omitted.

Without understanding the level of detail required, which we do not yet know, we cannot say. When I think of English specifications that (generally) aim to be very precise, I think of laws. Laws do not read like plain, common language, because plain common language is bad at being specific. Interpreting and creating laws requires an education on par with that required of an engineer, often greater.

Laws being unreadable is largely an Enlish-language problem zo. I have no problem reading them in my native language. Not requiring massive context size of case law makes things easier still. Big part of being a lawyer is having the same context with all the other lawyers and knowing what was already decided and what possible new interpretation is likely to be accepted by everyone else.

> Big part of being a lawyer is having the same context with all the other lawyers and knowing what was already decided and what possible new interpretation is likely to be accepted by everyone else.

And to create software specifications with language, the same thing will need to happen. You’ll need shared terminology and context that the LLM will correctly and consistently interpret, and that other engineers will understand. This means that very specific meanings become attached to certain words and phrases. Without this, you aren’t making precise specifications. To create and interpret these specifications will require learning the language of the specs. It may well still be easier than code - but then it would also be less precise.

Post reply on HN