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

Copilot regurgitating Quake code, including sweary comments

twitter.com

Post reply on HN
Print view View original

661–670 of 672 posts

Re: Copilot regurgitating Quake code, including sweary comments

#661

Post by caconym_ »

Filligree wrote: post #597
caconym_ wrote: post #397

Earlier quoted context omitted.

As someone who gets paid to write code (nominally) and has also written a few novels, I don't agree with this characterization. From what I've seen of Copilot, it's more like having a text editor generate your next sentence or paragraph^[1]. The idea (as I see it) is that you might use it to generate some prose "boilerplate", e.g. environmental descriptions, and hack up the results until you're satisfied. It's conten…

> ^[1] At least one tool like this (using GPT-3) has been posted on HN. At this point in time I wouldn't use it, but I have to admit that it was sort of cool. Have a poke at novelai.net if you get a chance. It's... not very smart. It's pretty decent at wordcrafting, though, and as an amateur writer I find it invaluable for busting writer's block. Probably if you spend all day writing fiction you'll find ways around t…

In case you're interested, this is the post I was thinking about: https://news.ycombinator.com/item?id=27032828

The application itself is called "Sudowrite". I guess there are probably a bunch of them at this point.

Re: Copilot regurgitating Quake code, including sweary comments

#662

Post by icebraining »

hermitdev wrote: post #660
willis936 wrote: post #614

Earlier quoted context omitted.

It doesn't need to be. If the license isn't positively exactly permissive then you can't use it.

Can you even trust that the License in a random repo is accurate and expresses the actual copyright of all the contained code? I guess my point is, you can't be positive that even if you're following the license in a repo you forked that the repo owner hasn't already violated someone else's license, and now transitively, so have you.

> Can you even trust that the License in a random repo is accurate and expresses the actual copyright of all the contained code?

In fact, that seems to be exactly the problem shown in the tweet - someone copy-pasted the quake source and slapped a different license on it, and copilot blindly trusted the new license.

Re: Copilot regurgitating Quake code, including sweary comments

#663

Post by computerex »

abeppu wrote: post #659
computerex wrote: post #652

Earlier quoted context omitted.

I said program synthesis good enough to replace programmers requires AGI. Program synthesis based off of informal specifications in natural language. Not talking about highly constrained environments with formal specs. I am not belittling the work going in this space, and I’m sure for highly constrained and narrow use cases a lot can be done even now. But I believe solving the general problem of program synthesis bas…

I think you're holding text-based approaches and synthesis based approaches to radically different expectations. Copilot isn't approaching replacing programmers; presumably a programmer is invoking it, deciding what to keep or change, etc, i.e. generating parts of programs under the guidance of a human programmer. Synthesis can work at the level of providing an expression or a helper function, as a useful tool under…

To be clear I wasn’t dismissing anything, that was not my intent. I think as a programmer assist text based approaches work and I really like copilot for what it is.

I was merely saying that for the holy grail, program synthesis from informal spec generalised to any domain, the approach will have to be different.

Re: Copilot regurgitating Quake code, including sweary comments

#664

Post by YeGoblynQueenne »

computerex wrote: post #657
YeGoblynQueenne wrote: post #656

Earlier quoted context omitted.

>> I am not belittling the work going in this space, and I’m sure for highly constrained and narrow use cases a lot can be done even now. No. Program synthesis approaches work very well for a broad array of problems, not for "highly constrained and narrow use cases"- that is a misconception of the kind that results from lack of familiarity with modern program synthesis. Here's a good recent review of the field: https…

If program synthesis is as far advanced as you say it is, how come I make six figures doing something that you seem to be arguing can be totally automated? The reality seems to disagree with your statements. Program synthesis is as of right now limited to academic research and highly narrow use cases. If the opposite was true, I’d be out of a job. I think copilot is probably the first product of its type that might m…

The purpose of program synthesis is not to get programmers out of a job. Rather, it's a tool to help programmers better do their job. I think it's easy to see why you're not using it. With few exceptions, advances in research take many years to percolate down to the industry. And of course the industry is famous for following trends without real understanding of anything.

Anyway the review I linked to has some examples of real-world applications of program synthesis. Don't be afraid to read it- it's light on formal notation and you don't need special skills to understand it. I appreciate that it's a long document but there's a Table of Contents at the start and you should be able to skim through in a short time just to get a general idea of the subject.

Anyway I can see you're trying to "wing it" and reason from first principles about something you know nothing about, in true SWE style. Yet, you don't know what you don't know, so you start from the wrong assumptions ("fully automated" etc) and arrive at the wrong conclusions. That's no way to understand anything. It's certainly not going to give you any good idea about what's going on in an entire field of research you know nothing about.

Of course you're not obliged to know anything about program synthesis, but in that case, maybe consider sitting back and listening rather than expressing strong opinions with absolute conviction that is not supported by your knowledge? I think that will make a better conversation, and a better internet, for everyone.

Re: Copilot regurgitating Quake code, including sweary comments

#665

Post by YeGoblynQueenne »

computerex wrote: post #663
abeppu wrote: post #659

Earlier quoted context omitted.

I think you're holding text-based approaches and synthesis based approaches to radically different expectations. Copilot isn't approaching replacing programmers; presumably a programmer is invoking it, deciding what to keep or change, etc, i.e. generating parts of programs under the guidance of a human programmer. Synthesis can work at the level of providing an expression or a helper function, as a useful tool under…

To be clear I wasn’t dismissing anything, that was not my intent. I think as a programmer assist text based approaches work and I really like copilot for what it is. I was merely saying that for the holy grail, program synthesis from informal spec generalised to any domain, the approach will have to be different.

Who said that's the holy grail?

Again I think you're trying to imagine what program synthesis must be like, rather than trying to find out what it actually is like.

Re: Copilot regurgitating Quake code, including sweary comments

#666

Post by Loeffeldude »

marcosdumay wrote: post #323
axiosgunnar wrote: post #138

I hate to be the one that says this but I think it‘s true: "So you are an SWE and you take a break from work to go to Hackernews to complain that Github's Copilot, which is an AI-based solution meant to help SWEs, is utter shit and completely unusuable. And then you go back to writing AI-based solutions for some other profession. Which is totally not shit or anything.“ Can anybody put this more elegantly?

There are probably good ways to apply AI to software development (has anybody tried to build a linter already?). It is this product that is very bad. The same certainly apply to other tasks.

How would an AI linter even work? And how would it be better than just a regular linter?

Re: Copilot regurgitating Quake code, including sweary comments

#668

Post by computerex »

YeGoblynQueenne wrote: post #665
computerex wrote: post #663

Earlier quoted context omitted.

To be clear I wasn’t dismissing anything, that was not my intent. I think as a programmer assist text based approaches work and I really like copilot for what it is. I was merely saying that for the holy grail, program synthesis from informal spec generalised to any domain, the approach will have to be different.

Who said that's the holy grail? Again I think you're trying to imagine what program synthesis must be like, rather than trying to find out what it actually is like.

Intuition tells me it’s the holy grail, confirmed by tradition and literature.

You are being a little condescending btw, it’s not in the spirit of hacker news.

> The ability to automatically discover a program consistent with a given user intent (specification) is the holy grail of Computer Science.

https://drops.dagstuhl.de/opus/volltexte/2017/7128/pdf/LIPIc...

> Since the inception of AI in the 1950s, this problem has been considered the holy grail of Computer Science.

https://www.microsoft.com/en-us/research/publication/program...

https://dl.acm.org/doi/fullHtml/10.1145/242224.242304

> Automatic synthesis of programs has long been one of the holy grails of software engineering.

https://people.eecs.berkeley.edu/~sseshia/pubdir/icse10-TR.p...

Re: Copilot regurgitating Quake code, including sweary comments

#669

Post by YeGoblynQueenne »

computerex wrote: post #668
YeGoblynQueenne wrote: post #665

Earlier quoted context omitted.

Who said that's the holy grail? Again I think you're trying to imagine what program synthesis must be like, rather than trying to find out what it actually is like.

Intuition tells me it’s the holy grail, confirmed by tradition and literature. You are being a little condescending btw, it’s not in the spirit of hacker news. > The ability to automatically discover a program consistent with a given user intent (specification) is the holy grail of Computer Science. https://drops.dagstuhl.de/opus/volltexte/2017/7128/pdf/LIPIc... > Since the inception of AI in the 1950s, this problem…

Your links say that program synthesis in general is the holy grail of computer science etc, you said that the holy grail is "program synthesis from informal spec" and by that you meant a natural language specification as per the context of our conversation so far. Are you now trying to subtly shift the goalposts?

If so, please leave them alone. You have no reason to assume that program synthesis from a natural language specification is "the holy grail" of anything. But I'm glad that our conversation at least made you look up a few links, even if only to try and win the internet conversation from what it looks like.

So what did you learn, from what you read about program synthesis? Can you see why your assumptions earlier on, about "narrow use cases" and the like were wrong?

Edit: btw, the Freuder paper you linked is about constraint prorgamming, not program synthesis.

And did you notice that one of your links above is the abstract of the review paper I proposed you read, earlier?

Re: Copilot regurgitating Quake code, including sweary comments

#670

Post by computerex »

YeGoblynQueenne wrote: post #669
computerex wrote: post #668

Earlier quoted context omitted.

Intuition tells me it’s the holy grail, confirmed by tradition and literature. You are being a little condescending btw, it’s not in the spirit of hacker news. > The ability to automatically discover a program consistent with a given user intent (specification) is the holy grail of Computer Science. https://drops.dagstuhl.de/opus/volltexte/2017/7128/pdf/LIPIc... > Since the inception of AI in the 1950s, this problem…

Your links say that program synthesis in general is the holy grail of computer science etc, you said that the holy grail is "program synthesis from informal spec" and by that you meant a natural language specification as per the context of our conversation so far. Are you now trying to subtly shift the goalposts? If so, please leave them alone. You have no reason to assume that program synthesis from a natural langua…

Look, I think the main disagreement here is that you don’t seem to consider spec inference as part of the program synthesis process, whereas I do. Your position may very well be correct from an academic point of view.

From my perspective, spec inference from informal spec is the main thing to solve. Because for formal specs, I’d just be programming in a declarative language to create the formal spec.

Spec by example won’t scale because you can’t provide examples across the entire domain for apps of real world complexity.

Once spec inference is solved, then you are just left with a search problem. I understand that the search space is freakin huge but I’d still say the latter problem is easier to solve than the former.

And I’d guess that the problem of inferring a spec from an informal description is what requires AGI.

I hope this clarifies my POV. I don’t think we disagree, we just have different perspectives.

Post reply on HN