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

A sufficiently detailed spec is code

haskellforall.com

Post reply on HN
Print view View original

191–200 of 376 posts

Re: A sufficiently detailed spec is code

#191

Post by skywhopper »

bad_username wrote: post #145

> There is no world where you input a document lacking clarity and detail and get a coding agent to reliably fill in that missing clarity and detail That is not true, and the proof is that LLMs _can_ reliably generate (relatively small amounts of) working code from relatively terse descriptions. Code is the detail being filled in. Furthermore, LLMs are the ultimate detail fillers, because they are language interpolat…

“LLMs _can_ reliably generate (relatively small amounts of) working code from relatively terse descriptions”

Only with well-known patterns that represent shared knowledge specified elsewhere. If the details they “fill in” each time differ in ways that change behavior, then the spec is deficient.

If we “figure out” how to write such detailed specs in the future, as you suggest, then that becomes the “code”.

Re: A sufficiently detailed spec is code

#192

Post by mike_hearn »

Gabriel439 wrote: post #109
baxtr wrote: post #69

Earlier quoted context omitted.

Isn’t most standard software these days a permutation of things already done before?

Author here: it's not even clear that agents can reliably permute their training data (I'm not saying that it's impossible or never happens but that it's not something we can take for granted as a reliable feature of agentic coding). As I mentioned in one of the footnotes in the post: > People often tell me "you would get better results if you generated code in a more mainstream language rather than Haskell" to which…

Your argument is far too dependent on observations made about the model's ability with Haskell, which is irrelevant. The concepts in Haskell are totally different to almost any other language - you can't easily "generalize" from an imperative strict language like basically everything people really use to a lazy pure FP language that uses monads for IO like Haskell. The underlying concepts themselves are different and Haskell has never been mainstream enough for models to get good at it.

Pick a good model, let it choose its own tools and then re-evaluate.

Re: A sufficiently detailed spec is code

#193

Post by skywhopper »

tibbe wrote: post #185
lmm wrote: post #173

Earlier quoted context omitted.

> LLMs _can_ reliably generate (relatively small amounts of) working code from relatively terse descriptions. Code is the detail being filled in. They can generate boilerplate, sure. Or they can expand out a known/named algorithm implementation, like pulling in a library. But neither of those is generating detail that wasn't there in the original (at most it pulls in the detail from somewhere in the training set).

They do more than that. If you ask for ui with a button that button won't be upside down even if you didn't specify its orientation. Lots of the detail can be inferred from general human preferences, which are present in the LLMs' training data. This extends way beyond CS stuff like details of algorithm implementations.

That’s exactly what they said. Details “elsewhere in its training set”.

Re: A sufficiently detailed spec is code

#195

Post by duesabati »

ACV001 wrote: post #167

I don't agree. The code is much more than the spec. In fact, the typical project code is 90% scaffolding and infrastructure code to put together and in fact contains implementation details specific to the framework you use. And only 10% or less is actual "business logic". The spec doesn't have to deal with language, framework details, so by definition spec is the minimum amount of text necessary to express the busine…

With ALL due respect (seriously), this is just a misconception of yours.

When you write software to solve a problem you start with as little as possible details such that when you read it, it would only talk about the business logic. What I mean by that? That you abstract away any other stuff that does not concern the domain you are in, for example your first piece of code should never mention any kind of database technology, it should not contain any reference to a specific communication layer (HTTP for example), and so on.

When you get to this, you have summarized the "spec", and usually it can be read very easily by a non-techincal person (but obviously is a "domain expert") and can also be very testable.

I hope this helps on why the author is right 100%

Re: A sufficiently detailed spec is code

#196

Post by mike_hearn »

grey-area wrote: post #132
rdevilla wrote: post #7

I think it's only a matter of time before people start trying to optimize model performance and token usage by creating their own more technical dialect of English (LLMSpeak or something). It will reduce both ambiguity and token usage by using a highly compressed vocabulary, where very precise concepts are packed into single words (monads are just monoids in the category of endofunctors, what's the problem?). Grammat…

Have you just reinvented programming languages and reinforced the author's point? Setting aside the problem of training, why bother prompting if you’re going to specify things so tightly that it resembles code?

Programming languages admit only unambiguous text. What he's proposing is more like EARS, Gherkin or Planguage.

Re: A sufficiently detailed spec is code

#198

Post by jamiemallers »

hintymad wrote: post #28

> A sufficiently detailed spec is code This is exactly the argument in Brooks' No Silver Bullet. I still believe that it holds. However, my observation is that many people don't really need that level of details. When one prompts an AI to "write me a to-do list app", what they really mean is that "write me a to-do list app that is better that I have imagined so far", which does not really require detailed spec.

[dead]

Re: A sufficiently detailed spec is code

#199

Post by mike_hearn »

nomel wrote: post #12
rdevilla wrote: post #7

I think it's only a matter of time before people start trying to optimize model performance and token usage by creating their own more technical dialect of English (LLMSpeak or something). It will reduce both ambiguity and token usage by using a highly compressed vocabulary, where very precise concepts are packed into single words (monads are just monoids in the category of endofunctors, what's the problem?). Grammat…

Let's use a non-ambiguous language for this. May I suggest Lojban [1][2]? [1] https://en.wikipedia.org/wiki/Lojban [2] Someone speaking it: https://www.youtube.com/watch?v=lxQjwbUiM9w

Lojban allows you to speak ambiguously, it just disallows grammatical ambiguity because in the 70s it was hypothesized that NLP understanding was impossible so humans would have to adapt instead of computers. That debate is over; understanding grammar is solved. The new debate is over semantic ambiguity.

Re: A sufficiently detailed spec is code

#200

Post by rdevilla »

grey-area wrote: post #132
rdevilla wrote: post #7

I think it's only a matter of time before people start trying to optimize model performance and token usage by creating their own more technical dialect of English (LLMSpeak or something). It will reduce both ambiguity and token usage by using a highly compressed vocabulary, where very precise concepts are packed into single words (monads are just monoids in the category of endofunctors, what's the problem?). Grammat…

Have you just reinvented programming languages and reinforced the author's point? Setting aside the problem of training, why bother prompting if you’re going to specify things so tightly that it resembles code?

[dead]
Post reply on HN