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

261–270 of 376 posts

Re: A sufficiently detailed spec is code

#261

Post by skydhash »

fmap wrote: post #227

I agree with most of what the author is saying, but the slogan that "a sufficiently detailed spec is code" can be misunderstood as "a sufficiently detailed spec is a program". The statement is only true if you read "code" as "statement in a formal language". Here's a (sketch of a) specification for a compiler: > For every specification satisfied by the input program, the output program satisfies the same specificatio…

But that is not a specification for a compiler. That is just one of the requirement. It’s still missing all the error cases that can happen. Granted, most of those decisions will be taken at implementation time or during design discussions, but I believe if we noted them down, it would have been longer than the code. It’s just that people don’t bother and refer to the code for these kind of information.

Re: A sufficiently detailed spec is code

#262

Post by randusername »

Safety-critical perspective:

Specification means requirements. I like EARS [0] syntax for requirements.

e.g. "while an error is present, the software shall ignore keypresses"

Requirements are not code at all, they are expectations about what the code does; it is the contract about what developers will be held accountable to. Putting implementation details in requirements is a rookie mistake because it takes agency away from the engineers in finding the best solution.

The spec discussed in this article is more akin to the level of detail appropriate in an interface control document (ICD). Very common for a requirement to declare the software shall be compliant to a revision of an ICD.

My own thoughts are: like a good systems engineer that recognizes the software engineers know their domain better than they, we should write specification for AI that leaves room for it to be more clever than we ourselves are. What's the point of exhaustive pseudocoding, it's worse coding. Align on general project preferences, set expectations, and concentrate effort on verifying.

[0]: https://alistairmavin.com/ears/

Re: A sufficiently detailed spec is code

#263

Post by zombot »

randusername wrote: post #262

Safety-critical perspective: Specification means requirements. I like EARS [0] syntax for requirements. e.g. "while an error is present, the software shall ignore keypresses" Requirements are not code at all, they are expectations about what the code does; it is the contract about what developers will be held accountable to. Putting implementation details in requirements is a rookie mistake because it takes agency aw…

> for AI that leaves room for it to be more clever than we ourselves are.

How probable is that given that LLMs output the average of their training data? Your own cleverness would have to be below average for this to hold.

Re: A sufficiently detailed spec is code

#264

Post by 9rx »

quotemstr wrote: post #95
9rx wrote: post #82

Earlier quoted context omitted.

It says a sufficiently detailed spec is code. Your spec lacks details that could be added.

If you're defining "spec" that way, the word is meaningless. The point of a spec is what it doesn't say.

It's turtles all the way down. If you write your spec in C you can get pretty detailed into how sin is implemented, but not fully. The compiler is going to take your spec and still do things with it that you didn't say, like optimize it in ways you never imagined possible.

If "spec" doesn't imply that, what does it mean to you? Or maybe you are suggesting that C "code" isn't code[1] either?

[1] By the original definition of code that is actually quite true, but I think we can agree the term, as normally used, has evolved over the years?

Re: A sufficiently detailed spec is code

#265

Post by bee_rider »

interstice wrote: post #240
vbezhenar wrote: post #237

Earlier quoted context omitted.

This is not correct. They can say "sorry" which makes them as accountable as ordinary developer.

I've found recent versions of Claude and codex to be reluctant in this regard. They will recognise the problem they created a few minutes ago but often behave as if someone else did it. In many ways that's true though, I suppose.

Does it do this for really cut and dry problems? I’ve noticed that ChatGPT will put a lot of effort into (retroactively) “discovering” a basically-valid alternative interpretation of something it said previously, if you object on good grounds. Like it’s trying to evade admitting that it made a mistake, but also find some say to satisfy your objection. Fair enough, if slightly annoying.

But I have also caught it on straightforward matters of fact and it’ll apologize. Sometimes in an over the top fashion…

Re: A sufficiently detailed spec is code

#266

Post by PessimalDecimal »

ithkuil wrote: post #235
svara wrote: post #159

The vibe coding maximalist position can be stated in information theory terms: That there exists a decoder that can decode the space of useful programs from a much smaller prompt space. The compression ratio is the vibe coding gain. I think that way of phrasing it makes it easier to think about boundaries of vibe coding. "A class that represents (A) concept, using the (B) data structure and (C) algorithms for methods…

It's not necessarily just the terseness. Terseness might be a selling point for people who have already invested in training themselves to be fluent with programming languages and the associated ecosystem of tooling. But there is an entire cohort of people who can think about specifying systems but lack the training to sdo so so using the current methods and see a lower barrier to entry in the natural language. That…

"[T]here is an entire cohort of people who can think about specifying systems but lack the training to sdo so so using the current methods and see a lower barrier to entry in the natural language."

"Specifying" is the load-bearing term there. They are describing what they want to some degree, how how specifically?

Re: A sufficiently detailed spec is code

#267

Post by PessimalDecimal »

svara wrote: post #159

The vibe coding maximalist position can be stated in information theory terms: That there exists a decoder that can decode the space of useful programs from a much smaller prompt space. The compression ratio is the vibe coding gain. I think that way of phrasing it makes it easier to think about boundaries of vibe coding. "A class that represents (A) concept, using the (B) data structure and (C) algorithms for methods…

What you describe is more or less exactly algorithmic information theory. From https://en.wikipedia.org/wiki/Algorithmic_information_theory:

"Informally, from the point of view of algorithmic information theory, the information content of a string is equivalent to the length of the most-compressed possible self-contained representation of that string. A self-contained representation is essentially a program—in some fixed but otherwise irrelevant universal programming language—that, when run, outputs the original string."

Where it gets tricky is the "self-contained" bit. It's only true with the model weights as a code book, e.g. to allow the LLM to "know about" Slack.

Re: A sufficiently detailed spec is code

#268

Post by tomasz-tomczyk »

I'm using obra superpowers plugin in CC and the plans it produces are very code-heavy, which is great for reviewing - I catch issues early. It's quite verbose however and if your codebase moves quickly, the code might have bad/stale examples.

Those very detailed specs then let agents run for a long time without supervision so nice for multi tasking :)

Re: A sufficiently detailed spec is code

#269

Post by mathgradthrow »

Someone wrote: post #157
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…

> That is not true, and the proof is that LLMs _can_ reliably generate (relatively small amounts of) working code from relatively terse descriptions. LLMs can generate (relatively small amounts of) working code from relatively terse descriptions, but I don’t think they can do so _reliably_. They’re more reliable the shorter the code fragment and the more common the code, but they do break down for complex description…

> try tweaking the description of a widely-known algorithm just a little bit and see how good the generated code follows the spec.

this works well for me

Re: A sufficiently detailed spec is code

#270

Post by bluGill »

carlmr wrote: post #111
ms_menardi wrote: post #65

Earlier quoted context omitted.

It could be an issue of discoverability too. Maybe they just haven't found the to-do app that does what they want, and it's easier to just... make one from scratch.

Which is not getting better. I'd pay you 10€ for a TODO app that improved my life meaningfully. It would obviously need to have great UX and be stable. Those are table stakes. I don't have the time to look at all these apps though. If somebody tells me they made a great TODO app, I'm already mentally filtering them out. There's just too much noise here. Does your TODO app solve any meaningful problem beyond the bare…

> It would obviously need to have great UX

There is the problem. Todo apps are easy to make. However making one that is actually useful for tracking todo items it hard. Getting the todo into the app is harder than writing it on paper. Getting reminders at a useful time is hard (now is not a great time to fix that broken widget - it needs parts not in the budget, I'm at work, it needs a couple hours of dedicated time and I have something else coming up...). I've tried a few different ones, most are a combination of too complex and not complex enough at the same time.

Post reply on HN