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

251–260 of 376 posts

Re: A sufficiently detailed spec is code

#251

Post by dwb »

macinjosh wrote: post #24

IMHO, LLMs are better at Python and SQL than Haskell because Python and SQL syntax mirrors more aspects of human language. Whereas Haskell syntax reads more like a math equation. These are Large _Language_ Models so naturally intelligence learned from non-code sources transfers better to more human like programming languages. Math equations assume the reader has context not included in the written down part for what…

I have found recent models to be quite respectable at Haskell, given a couple of initial nudges on style - but that’s true of anything.

Re: A sufficiently detailed spec is code

#254

Post by skydhash »

abainbridge wrote: post #226
angry_octet wrote: post #162

A spec is an envelope that contains all programs that comply. Creating this spec is often going to be harder than writing a single compliant program. Since every invocation of an LLM may create a different program, just like people, we will see that the spec will leave much room for good and bad implementations, and highlight the imprecision in the spec. Once we start using a particular implementation it often become…

> A spec is an envelope that contains all programs that comply. Creating this spec is often going to be harder than writing a single compliant program. This perfectly explains the feeling I had when, 20 years into my career, I had to start writing specs. I could never quite put my finger on why it was harder than coding. My greater familiarity with coding didn't seem a sufficient explanation. When writing a line of s…

> But code is just a spec as far as, say, a C compiler is concerned. The compiler is free to implement the assembly however it likes.

Not at all. Code is formal, and going from C to assembly os deterministic. While the rules may be complex, they are still rules, and the compiler can’t stray away from them.

Writing C code is easier than writing assembly because it’s an easier notation for thinking. It’s like when hammering a nail. Doing it with a rock is hard. But using a hammer is better. You’re still hitting the nail with a hard surface, but the handle, which is more suitable for a human hand, makes the process easier.

So programming languages are not about the machine performance, they are about easier reasoning. And good programmers can get you to a level above that with proper abstraction and architecture, and give you concepts that directly map to the problem space (Gui frameworks instead of directly rendering to a framebuffer, OS syscall instead of messing with hardware,…).

Re: A sufficiently detailed spec is code

#255

Post by skydhash »

duesabati wrote: post #195
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 te…

Aka essential and accidental complexity. Most good code will abstract the latter, even if it’s only a shim.

Re: A sufficiently detailed spec is code

#256

Post by angry_octet »

abainbridge wrote: post #226
angry_octet wrote: post #162

A spec is an envelope that contains all programs that comply. Creating this spec is often going to be harder than writing a single compliant program. Since every invocation of an LLM may create a different program, just like people, we will see that the spec will leave much room for good and bad implementations, and highlight the imprecision in the spec. Once we start using a particular implementation it often become…

> A spec is an envelope that contains all programs that comply. Creating this spec is often going to be harder than writing a single compliant program. This perfectly explains the feeling I had when, 20 years into my career, I had to start writing specs. I could never quite put my finger on why it was harder than coding. My greater familiarity with coding didn't seem a sufficient explanation. When writing a line of s…

C has a simpler mapping to assembly than most languages, so you are doing most of the high level translation when writing C. But even C compilers have considerable scope for weirdness, hence projects like CompCert.

But much of the code we run today is JIT executed, and that leaves ample room for exploiting with weird machines. Eg the TOCTOU in the Corina exploit.

Even at this very low level, full coverage specs require years of careful formal methods work. We have no hope of doing it at for vibe coding, everything will be iterative, and if TDD helps then good, but specs are by no means easier than code.

Re: A sufficiently detailed spec is code

#257

Post by onion2k »

lmm wrote: post #165
onion2k wrote: post #112

Earlier quoted context omitted.

Code is a specific implementation of a spec. You can even use it as a spec if you're happy to accept exactly what the code does. But the code doesn't tell you what was supposed to be built so the code is not a spec. Simple thought experiment: Imagine you have a spec and some code that implements it. You check it, and find that a requirement in the spec was missed. Obviously that code is not the spec; the spec is the…

> Obviously that code is not the spec; the spec is the spec. But also you couldn't even use the code as a spec because it was wrong. Or the spec was wrong and the code was right; that happens more often than you might think. If we view it through the lens of "you have two specs, one of which is executable" then obviously you could have made an error in either spec, and obviously writing two specs and checking for mis…

That assumes that the two have equal 'authority' though. Really one of the two should be the source of truth, and that's usually the spec. That's definitely the one that the should win if there's a difference in my experience.

Re: A sufficiently detailed spec is code

#258

Post by mbesto »

pablobaz wrote: post #231
MoreQARespect wrote: post #223

Earlier quoted context omitted.

Humans have the ability to retrospect, push back on a faulty spec, push back on an unclarified spec, do experiments, make judgement calls and build tools and processes to account for their own foibles.

which bits of this do you think llm based agents can't do?

LLMs by their nature are not goal orientated (this is fundamental difference of reinforcement learning vs neural networks for example). So a human will have the, let's say, the ultimate goal of creating value with a web application they create ("save me time!"). The LLM has no concept of that. It's trying to complete a spec as best it can with no knowledge of the goal. Even if you tell it the goal it has no concept of the process to achieve or confirm the goal was attained - you have to tell it that.
Post reply on HN