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

111–120 of 376 posts

Re: A sufficiently detailed spec is code

#111

Post by carlmr »

ms_menardi wrote: post #65
lmm wrote: post #48

Earlier quoted context omitted.

> 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. If someone was making a serious request for a to-do list app, they presumably want it to do something different from or better than the dozens of to-do list apps that are already out there. Which would require them t…

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 minimum? Does it solve your procrastination? Does it remind you at the right time?

If it doesn't answer this in the first 2 seconds of your pitch you're out.

Re: A sufficiently detailed spec is code

#112

Post by onion2k »

lmm wrote: post #53
ulrikrasmussen wrote: post #45

A corollary of this statement is that code without a spec is not code. No /s, I think that is true - code without a spec certainly does something, but it is, by the absence of a detailed spec, undefined behavior.

On the contrary, code is a spec. In a decent language it should look like one.

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 spec. But also you couldn't even use the code as a spec because it was wrong. Now remove the spec.

Is the code a spec for what was supposed to be built? No. A requirement was missed. Can you tell from just the code? Also no. You need a two separate sources that tell you what was meant to be written in case the either of them is wrong. That is usually a spec and the code.

They could both be wrong, and often are, but that's a people problem.

Re: A sufficiently detailed spec is code

#113

Post by 21asdffdsa12 »

trane_project wrote: post #98

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…

Don't you also need to specify the error-cases at each stage and at what level of the system you would like to handle them (Log away, throw ever more up, Inform others, create Tasks, etc.)?

I found that to be really vital for good code. https://fsharpforfunandprofit.com/rop/

Re: A sufficiently detailed spec is code

#114

Post by School-Cotton »

noosphr wrote: post #74
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…

Or they could look at the past few centuries of language theory and start crafting better tokenizers with inductive biases. We literally have proof that an iron age ontology of meaning as represented in Chinese characters is 40% more efficient than naive statistical analysis over a semi phonetic language and we still are acting like more compute will solve all our problems.

> We literally have proof that an iron age ontology of meaning as represented in Chinese characters is 40% more efficient than naive statistical analysis over a semi phonetic language and we still are acting like more compute will solve all our problems.

Post a link because until you do, I’m almost certain this is pseudoscientific crankery.

Chinese characters are not an “iron age ontology of meaning” nor anything close to that.

Also please cite the specific results in centuries-old “language theory” that you’re referring to. Did Saussure have something to say about LLMs? Or someone even older?

Re: A sufficiently detailed spec is code

#115

Post by 21asdffdsa12 »

jiggawatts wrote: post #104
trane_project wrote: post #98

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.

The hovering selector, throneing over busy agents, picking the chosen parts condemning the rest..

Re: A sufficiently detailed spec is code

#116

Post by krethh »

philipp-gayret wrote: post #90
nostrademons wrote: post #83

Earlier quoted context omitted.

Most of the economically valuable software written is pretty unique, or at least is one of few competitors in a new and growing niche. This is because software that is not particularly unique is by definition a commodity, with few differentiators. Commodity software gets its margins competed away, because if you try to price high, everybody just uses a competitor. So goes the AI paradox: it's really effective at writ…

Could you give some examples? I can only imagine completely proprietary technology like trading or developing medicine. I have worked in software for many years and was always paid well for it. None of it was particularly unique in any way. Some of it better than others, but if you could show that there exists software people pay well for that AI cannot make I would be really impressed. With my limited view as softwa…

You know how whenever you shuffle a deck of cards you almost certainly create an order that has never existed before in the universe?

Most software does something similar. Individual components are pretty simple and well understood, but as you scale your product beyond the simple use cases ("TODO apps"), the interactions between these components create novel challenges. This applies to both functional and non-functional aspects.

So if "cannot make with AI" means "the algorithms involved are so novel that AI literally couldn't write one line of them", then no - there isn't a lot of commercial software like that. But that doesn't mean most software systems aren't novel.

Re: A sufficiently detailed spec is code

#117

Post by mfabbri77 »

layer8 wrote: post #92
mfabbri77 wrote: post #81

Earlier quoted context omitted.

In my experience, the further you move away from the user and toward the hardware and fundamental theoretical algorithms, the less true this becomes. This is very true for an email client, but very untrue for an innovative 3D rendering engine technology (just an example).

An email client is highly nontrivial, due to the complexities of the underlying standards, and how the real implementations you have to be compatible with don’t strictly follow them. Making an email client that doesn’t suck and is fully interoperable is quite an ambitious endeavor.

The point was to answer the question: "Can every piece of software be viewed as a permutation of software that has already been developed?" In my opinion, an email client is a more favorable example than a 3D engine. In fields where it is necessary to differentiate, improve, or innovate at the algorithmic level, where research and development play a fundamental role, it is not simply a matter of permuting software or leveraging existing software components by simply assembling them more effectively.

Re: A sufficiently detailed spec is code

#118

Post by trane_project »

21asdffdsa12 wrote: post #113
trane_project wrote: post #98

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…

Don't you also need to specify the error-cases at each stage and at what level of the system you would like to handle them (Log away, throw ever more up, Inform others, create Tasks, etc.)? I found that to be really vital for good code. https://fsharpforfunandprofit.com/rop/

It's mostly rust projects so error handling is writing `?` and defining the signatures as either Option or Result for the most part.

Re: A sufficiently detailed spec is code

#120

Post by nostrademons »

philipp-gayret wrote: post #90
nostrademons wrote: post #83

Earlier quoted context omitted.

Most of the economically valuable software written is pretty unique, or at least is one of few competitors in a new and growing niche. This is because software that is not particularly unique is by definition a commodity, with few differentiators. Commodity software gets its margins competed away, because if you try to price high, everybody just uses a competitor. So goes the AI paradox: it's really effective at writ…

Could you give some examples? I can only imagine completely proprietary technology like trading or developing medicine. I have worked in software for many years and was always paid well for it. None of it was particularly unique in any way. Some of it better than others, but if you could show that there exists software people pay well for that AI cannot make I would be really impressed. With my limited view as softwa…

Were you around when any of Google Maps, Twitter, AirBnB, or HN were first released? Aside from AirBnB (whose primary innovation was the business model, and hitting the market right during the global financial crisis when lots of families needed extra cash), they were each architecturally quite different from software that had come before.

Before Google Maps nobody had ever pushed a pure-Javascript AJAX app quite so far; it came out just as AJAX was coined, when user expectations were that any major update to the page required a full page refresh. Indeed, that's exactly what competitor MapQuest did: you had to click the buttons on the compass rose to move the map, it moved one step at a time, and it fully reloaded the page with each move. Google Maps's approach, where you could just drag the map and it loaded the new tiles in the background offscreen, then positioned and cropped everything with Javascript, was revolutionary. Then add that it gained full satellite imagery soon after launch, which people didn't know existed in a consumer app.

Twitter's big innovation was the integration of SMS and a webapp. It was the first microblog, where the idea was that you could post to your publicly-available timeline just by sending an SMS message. This was in the days before Twilio, where there was no easy API for sending these, you had to interface with each carrier directly. It also faced a lot of challenges around the massive fan-out of messages; indeed, the joke was that Twitter was down more than it was up because they were always hitting scaling limits.

HN has (had?) an idiosyncratic architecture where it stores everything in RAM and then checkpoints it out to disk for persistence. No database, no distribution, everything was in one process. It was also written in a custom dialect of Lisp (Arc) that was very macro-heavy. The advantage of this was that it could easily crank out and experiment with new features and new views on the data. The other interesting thing about it was its application of ML to content moderation, and particularly its willingness to kill threads and shadowban users based on purely algorithmic processes.

Post reply on HN