Live data from Hacker News

A sufficiently detailed spec is code

haskellforall.com

371–376 of 376 posts

Re: A sufficiently detailed spec is code

#371
post #186

Earlier quoted context omitted.

The hard bit of programming has never been knowing the symbols to tell the computer what to do. It is more difficult to use a completely unknown language, sure, but the paradigms and problem solving approaches are identical and thats the actual work, not writing the correct words.

Saying that the paradigms of Python and Haskell are the same makes it sound like you don’t know either or both of those languages. They are not just syntactically different. The paradigms literally are different. Python is a high level duck typed oo scripting language and Haskell is a non-oo strongly typed functional programming language. They’re extremely far apart.

Other people have replied but to clarify my point, while two languages may operate with a focus on two seperate paradigms, the actual paradigms do not vary. OOP is still OOP whatever language you use, same for functional et al. Sure some languages are geared towards being used in certain ways, some very much so, but if you know the actual ways the language is largely irrelevant.

Re: A sufficiently detailed spec is code

#372
post #367

Earlier quoted context omitted.

All compilations do what I intended to do when I wrote the C code. But each compilation does the intended thing in a different way. The point I’m making is that determinism isn’t the key difference between compilers and LLMs. The key difference is that LLMs do not give semantic guarantees. I don’t care if they give the same output on the same input, just as I don’t care very much which C compiler I use.

> The point I’m making is that determinism isn’t the key difference between compilers and LLMs I think you misunderstood. Determinism is the the difference between natural language and code. It's not about LLMs vs compilers.

In my mind the most salient difference between code and natural language is that code has a formal semantics.

I’m still not entirely sure what people mean when they call a formal/natural language deterministic. As we’ve discussed, it can’t possibly mean that it has a single valid interpretation, since this is untrue of C code. If it means that code has a _precise set_ of interpretations, then I wouldn’t use the word deterministic for that.

Re: A sufficiently detailed spec is code

#373

I've been trying codex and claude code for the past month or so. Here's the workflow that I've ended up with for making significant changes. - Define the data structures in the code yourself. Add comments on what each struct/enum/field does. - Write the definitions of any classes/traits/functions/interfaces that you will add or change. Either leave the implementations empty or write them yourself if they end up being…

My twist on this is to first vibe code the solution with the aim of immediately replacing it. I’ve found that two to three iterations with various prompts or different models will often yield a surprising solution or some aspect I hadn’t thought of or didn’t know about. Then I throw away most or all of the code and follow your process, but with care to keep the good ideas from the LLMs, if any.

same, prototyping fast helps me understand what I'm building and the flows I want. It would not be possible to think of all the interactions and restrictions I'd want if I tried to do it on day 1.

Re: A sufficiently detailed spec is code

#374
post #175

Earlier quoted context omitted.

> - 1970s: abstracted away the algorithm -> OOP, standard libraries, UML Which was mostly a failure, to the point that there is a major movement towards languages that "abstract away" (in this sense) less , e.g. Rust. Certainly if the creators of UML are saying that AI is great, that gives me more confidence than ever that it's bunk.

UML was for various reasons, but libraries? When's the last time you wrote a sorting algorithm? The entire software ecosystem runs on dependencies. That failed? Rust uses crates to import those dependencies, which was one of its biggest innovations.

I would argue that library dependencies in Rust are significantly less abstracted away than in previous languages. The libraries themselves tend to be much more specific (rather than a huge utility library you'll have a crate that does one specific thing - and rather than "sort" it will be a specific sorting algorithm), you specify exactly the version you want rather than getting silently upgraded, and it's statically linked rather than being resolved at runtime. Yes reusing implementation code is not going away, but we're being more explicit about it.

Re: A sufficiently detailed spec is code

#375
post #134

Earlier quoted context omitted.

I read this attitude very often on HN. "If someone else has already built it before, your effort is a waste of time." To me, it has this "Someone else already makes money from it, go somewhere else where you dont have competition." Well, I get the drift... But... Not everyone is into getting rich. You know, some of us just have fun building things and learning while doing so. It really doesn't matter if the path has…

If you do it for fun then why do you care whether an LLM can do it well or not, which was the original argument? Shouldn't matter to you in that case.

If you dont know the answer to the question you just raised, having a discussion is pretty much useless, because it is so obvious. Just because I have fun building thinks doesn't mean I don't care about the tools to do so?

Re: A sufficiently detailed spec is code

#376
post #179

Absolute nonsense. A sufficiently detailed "spec" is the code. What is wrong with you people ? Pure nonsense, all they have to offer.

Please don't fulminate on HN. The guidelines make it clear we're trying for something better here. https://news.ycombinator.com/newsguidelines.html

[dead]
Post reply on HN