Comment by adinhitlore | Hacker News Reader

Comment by adinhitlore | Hacker News Reader

Parent Full thread

I'd say a very useful and simple formula one could device can look something like:

f(n) = x/y. value = goal/loc.

"goal" here is just arbitrary number of usefullnes of code that aligns with some common uility like say 10 = ASI/eternal happiness and immortaility or whatever while 1 being 'terminator' and 7, 8 being useful business code so on. loc is self-expplanatory.

>goal / >loc -> < 10/1 a; <goal / >loc -> < 10/1 b; <goal / <loc -> < 10/1 c; >goal / <loc -> = 10/1 d

So, the very best value possible will be say "d" 10, f(n) = 10/1 - any other of the 4 possible permutations aka options will lead to worse result:

But while such simple formula could illustrate the value of software project overall, a key detail ommited could be the lowest possible number a great goal may require, most people would agree writing ASI in just <100 words aka 'one line' is just not possible, or anything useful.

It's like complaining you could write 100 000 a day when the project is Operating system or 3dsmax clone, it surely will be better to finish it early and there is a lowest bar possible that cannot be decreased even with F# or whatever language that saves words.

I was not able to make much sense of that, but if you can create 10k+ lines of good C per day regardless of domain complexity, requirements etc, you could create ffmpeg solo including all codecs in under 6 months.

That would make you, approximately, the best programmer in the world.

well maybe but btw i swear this almost looks like P=NP but rather reversed P=NP lol, let me explain...in the classic p=np problem given to explain it it's the subset problem where it's easy to verify a solution, but not find it {25,39,22,12,29,18} - do any 2 numbers add to 47 and yeah the last 2 numbers: 18 and 29 add to 47. Yet here if you use LLM to make great product, you have a "solution" pretty quickly but verifying it will take some time...be it to test functionality or read every single line and understand it. It's such a weird logical puzzle! The llm throws you the solution basically saying 'i did it' and your verification takes longer, another way to look at is that your verification is the real solution while the code generation is the "verification"...confusing a lot.

edit: in my previous post i meant that the higher the challenge of the program / the lowest possible lines of code to implement it will be the best possible software one can make. So a software rated 10/10 in every aspect possible implemented in just a single line of code is the best possible program. If you write it in more lines of code, it's worse in terms of value, if you decrease the quality but keep the loc low...it's still not optimal since you sacrifice quality, if you decrease the quality but increase the loc that's the worst possible case.

It sucks to do a 2-line change that requires 2 weeks of validation :/

Agree that codegen can flip the effort from creating to validating. Some people believe the "true" intellectual capital created by the software development process is the understanding created inside the team's mind as they build it (not the code itself). Like, understanding of the domain, customers, market, how the software works, how they would build it again if they had the chance, their networks and relationships etc.

Probably it does hurt if codegen impacts that process. It's always been possible to externalise some of that understanding, by writing books, articles etc. I suppose what we are starting to see is that kind of intellectual capital will gradually reside in AI also. For well understood problems (TODO app, space invaders, etc) the model will have the actual understanding and everyone generating those apps for the first time would need to build it up.

I agree that 1 LOC that provides infinite value sounds like the "best possible program", but beyond that I can't see any hard and fast rules about LOC vs value, I think they're almost entirely uncorrelated. Mostly it's about what the lines do, but even then it's hard. What's more valuable: the bible, the script to star wars or a set of 747 technical manuals? Should they have used more or fewer words to achieve their goals?

Even with precise specifications the "best" way to implement large scale software is never clear and depends on many factors. Sometimes more duplication is better, sometimes you need more abstraction to reduce it. A lot depends on what your team (or contributors) are comfortable with and their abstraction ceiling.

Reply on news.ycombinator.com