Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

-​-dangerously-skip-reading-code

olano.dev

Post reply on HN
Print view View original

41–50 of 219 posts

Re: -​-dangerously-skip-reading-code

#41

Post by dnmc »

20k wrote: post #38
ramoz wrote: post #13

> If I had to roll out such a development process today, I’d make a standardized Markdown specification the new unit of knowledge for the software project. Product owners and engineers could initially collaborate on this spec and on test cases to enforce business rules. Those should be checked into the project repositories along with the implementing code. There would need to be automated pull-request checks verifyin…

What we really we need is some kind of more detailed spec language that doesn't have edge cases, where we describe exactly what we expect the generated code to do, and then formally verify that the now generated code matches the input spec requirement. It'd be super helpful to have something more formal with no ambiguity, especially because the english language tends to be pretty ambiguous in general which can result…

There are languages like Dafny that permit you to declare pre- and post-conditions for functions. Dafny in particular tries to automatically verify or disprove these claims with an SMT solver. It would be neat if LLMs could read a human-written contract and iterate on the implementation until it's provably correct. I imagine you'd have much higher confidence in the results using this technique, but I doubt that available models are trained appropriately for this use case.

Re: -​-dangerously-skip-reading-code

#42

Post by yibers »

phyzix5761 wrote: post #37

I wonder if with the speed of iteration with AI the industry will switch back to waterfall. Clear documentation first so the LLM can easily produce what's being asked with a round of testing before going back to the documentation stage and running it again. History does repeat itself.

We already switched

Re: -​-dangerously-skip-reading-code

#43

Post by zombot »

20k wrote: post #38
ramoz wrote: post #13

> If I had to roll out such a development process today, I’d make a standardized Markdown specification the new unit of knowledge for the software project. Product owners and engineers could initially collaborate on this spec and on test cases to enforce business rules. Those should be checked into the project repositories along with the implementing code. There would need to be automated pull-request checks verifyin…

What we really we need is some kind of more detailed spec language that doesn't have edge cases, where we describe exactly what we expect the generated code to do, and then formally verify that the now generated code matches the input spec requirement. It'd be super helpful to have something more formal with no ambiguity, especially because the english language tends to be pretty ambiguous in general which can result…

> where we describe exactly what we expect the generated code to do, and then formally verify that the now generated code matches the input spec requirement.

In ancient times we had tech to do exactly that: Programming languages and tests.

Re: -​-dangerously-skip-reading-code

#44

Post by 20k »

ramoz wrote: post #40
20k wrote: post #38

Earlier quoted context omitted.

What we really we need is some kind of more detailed spec language that doesn't have edge cases, where we describe exactly what we expect the generated code to do, and then formally verify that the now generated code matches the input spec requirement. It'd be super helpful to have something more formal with no ambiguity, especially because the english language tends to be pretty ambiguous in general which can result…

yes, am familiar with the "code is spec" trope. Shame us all for moving away from something so perfect, precise, and that "doesn't have edge cases." Hey - if you invent a programming language that can be used in such a way and create guaranteed deterministic behavior based on expressed desires as simple as natural language - ill pay a $200/m subscription for it.

As people are discovering, natural language is insufficiently precise to be able to specify edge cases. Any language precise enough to be formally verified against is a programming language

Re: -​-dangerously-skip-reading-code

#45

Post by vinnymac »

jmull wrote: post #29

The lesson I've learned from our new AI age is how little a large number of people who've worked in software development their entire careers understand software development. I suppose all the money floating around AI helps dummify everything, as people glom on to narratives, regardless of merit, that might position them to partake. What we actually have now is the ability to bang out decent quality code really fast…

I appreciate your insights in a sea of psychosis comments. I find it strange how many people think we have achieved the likes of Y2K flying cars 20 years ago, or the dream of having every car on the road be an electric fully self driving car by now (a promise made at least over a decade ago by several of these types).

The point I’m making is that we give the spotlight to people who are making absurd claims. We have not achieved the ability to remove the human from the loop and continually produce value-able outputs. Until we do, I don’t see how any of the claims made in this article are even close to anything more than simply gate-keeping slop.

Re: -​-dangerously-skip-reading-code

#46

Post by ramoz »

20k wrote: post #44
ramoz wrote: post #40

Earlier quoted context omitted.

yes, am familiar with the "code is spec" trope. Shame us all for moving away from something so perfect, precise, and that "doesn't have edge cases." Hey - if you invent a programming language that can be used in such a way and create guaranteed deterministic behavior based on expressed desires as simple as natural language - ill pay a $200/m subscription for it.

As people are discovering, natural language is insufficiently precise to be able to specify edge cases. Any language precise enough to be formally verified against is a programming language

we're going to end up speaking past each other - but generally I do agree with you and am not denouncing the importance of formal verification methods. I do think abstractions are going to dominate the human ux above them

Re: -​-dangerously-skip-reading-code

#47

Post by ElectricalUnion »

wizzwizz4 wrote: post #21
InsideOutSanta wrote: post #11

Earlier quoted context omitted.

Step 1: solve the halting problem.

You're probably thinking of Rice's theorem (a sort of generalised halting problem), but this task is actually way easier than that, since we're not trying to study arbitrary algorithms: we're trying to study the subset of human-comprehensible algorithms. Most of the things we want computers to do are things that, given enough time, someone can write a program to solve: and generally, those programs are not tricksy or…

I will give you a class of programs humans wrote and they want improved: LLMs.

Those were written by humans, and don't involve unsolved mathematics.

Is your claim tht you just need to solve comprehensibility of LLMs?

Figuring out epistemology and cognition to have a chance to reason about the outputs of a LLM seems to me way harder that traditional attempts to reason directly about algorithms.

Re: -​-dangerously-skip-reading-code

#48

Post by ninalanyon »

vinnymac wrote: post #45
jmull wrote: post #29

The lesson I've learned from our new AI age is how little a large number of people who've worked in software development their entire careers understand software development. I suppose all the money floating around AI helps dummify everything, as people glom on to narratives, regardless of merit, that might position them to partake. What we actually have now is the ability to bang out decent quality code really fast…

I appreciate your insights in a sea of psychosis comments. I find it strange how many people think we have achieved the likes of Y2K flying cars 20 years ago, or the dream of having every car on the road be an electric fully self driving car by now (a promise made at least over a decade ago by several of these types). The point I’m making is that we give the spotlight to people who are making absurd claims. We have n…

And if we do remove the human from the loop? What then, what are humans for? Do we get Keynes' idea that we only need to work a few hours a week or do we get a continuation and intensification of what we already have: a few high 'earners' and a sea of people struggling to make ends meet?

Re: -​-dangerously-skip-reading-code

#49

Post by vinnymac »

duskdozer wrote: post #14
Ecys wrote: post #4

very true. and we already know and agree with this. user experience/what the app actually does >>> actually implementing it. elon musk said this a looong time ago. we move from layer 1 (coding, how do we implement this?) to layer 2 thinking (what should the code do? what do we code? should we implement this? (what to code to get the most money?)) this is basic knowledge

Elon Musk has been saying Teslas would have fully autonomous self-driving within 1-3 years since 2013

I left a similar comment elsewhere in this thread. I still remember when so many people hallucinated that we would suddenly have flying cars by 2002 at the latest. If we achieve several more major improvements on current technology, these thoughts are interesting to consider. But not before that occurs.

We need the pragmatic engineer more than ever.

Re: -​-dangerously-skip-reading-code

#50

Post by __s »

soraminazuki wrote: post #24
wizzwizz4 wrote: post #21

Earlier quoted context omitted.

You're probably thinking of Rice's theorem (a sort of generalised halting problem), but this task is actually way easier than that, since we're not trying to study arbitrary algorithms: we're trying to study the subset of human-comprehensible algorithms. Most of the things we want computers to do are things that, given enough time, someone can write a program to solve: and generally, those programs are not tricksy or…

We can't create an algorithm determining whether a computer program halts or not, but we can write one that checks whether it conforms to natural language specifications much more easily? That makes no sense. There's no exception to the halting problem regarding "human comprehensible" computer programs.

They're saying most useful programs don't fall in the complete / correct divide. You can get a lot done while restricting yourself to provable programs
Post reply on HN