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

271–280 of 672 posts

Re: Copilot regurgitating Quake code, including sweary comments

#271

Post by biztos »

thayne wrote: post #261
gentleman11 wrote: post #94

Earlier quoted context omitted.

> The python example is using floats for currency. Dumb question, but what is the proper way to handle currency? Custom number objects? Strings for any number of decimal places?

An integer of the smallest denomination. For example, cents for the American dollar. And you probably would want to wrap it in a custom type to simplify displaying it properly, and maybe handle different currencies. If you language has a fixed point type that might also be appropriate, but that's pretty rare, and wouldn't work for currencies that aren't decimal (like the old british pound system).

Do they still use fractional cents (or whatever) in finance?

https://money.howstuffworks.com/personal-finance/financial-p...

Re: Copilot regurgitating Quake code, including sweary comments

#272

Post by vlovich123 »

bostonsre wrote: post #88
louthy wrote: post #5

This is utterly damning. I have already instructed my team that Copilot can never be used for our projects. Compromising the product because of unknowable license demands isn't acceptable in the professional world of software engineering. But if we put the licensing to one side for a moment... 1/ Everything I've seen it generate so far is 'imperative hell'. It is practically a 'boilerplate generator'. That might be u…

I'm not sure we should throw the baby out with the bath water here due to the large blurbs it stubs in when when it doesn't have a lot to go on in mostly empty files. It is a preview release. They are working on proper attribution of suggested code and explainability [1]. Having a stochastic parrot that types faster than I do would be useful in a lot of cases. Yes, better layers of abstraction could make us more prod…

I think it depends on how you look at it.

For small snippets that have likely been already written by someone else, this probably works great. For those though, the time savings is probably at most 5-10 min down to 1 or less. The challenge is that that’s not where my time goes unless I’m working in an unfamiliar language.

As someone who writes a lot of code quickly, I’m usually bottlenecked by reviews. For more complex changes I’m bottlenecked by understanding the problem and experimenting with solutions (and then reviews, domain-specific tests usually, fixing bugs etc). Writing code isn’t like waiting for code to compile since I’m not actually ending up task switching that frequently.

This does sound like a fantastic tool when I’m not familiar with the language although I wonder if it actually generates useful stuff that integrates well as the code gets larger (eg can I say “write an async function that allocates a record handle in the file with ownership that doesn’t outlive the open file’s lifetime”). I’m sure though that this is what a lot of people are overindexing on. For things like that I expect normal evolution of the product will work well. For things like “cool, understand your snippets but also weight my own codebase higher and understand the specifics of my codebase”, I think there’s a lot of groundbreaking research that would be required. That is what I see as a true productivity boost - I’d make this 100% required for anyone joining the codebase. The more mentorship can be offloaded, the lower the cost is to growing teams. OSS projects can more easily scale similarly.

Re: Copilot regurgitating Quake code, including sweary comments

#273

Post by adwn »

dralley wrote: post #204
pizza234 wrote: post #150

Earlier quoted context omitted.

This is a complex topic, mainly for two reasons: 1. it works on two layers (storage and code) 2. there is a context to take care of. [Modern] programming languages have decimal/rational data types, which (within limits) are exact. Where this is not possible, and/or it's undesirable for any reason, just use an int and scale it manually (e.g. 1.05 dollars = int 105). However, point 2 is very problematic and important t…

>[Modern] programming languages have decimal/rational data types This caveat is kind of funny, in light of COBOL having support for decimal / fixed precision data types baked directly into the language. It's not a problem with "non-modern" languages, it's a problem with C and many of its successors. That's precisely why many "non-modern" languages have stuck around so long. https://medium.com/the-technical-archaeolog…

> It's not a problem with "non-modern" languages, it's a problem with C and many of its successors.

Not really. Any semi-decent modern language allows the creation of custom types which support the desired behavior and often some syntactic sugar (like operator overloading) to make their usage more natural. Take C++, for example, the archetypal "C successor": It's almost trivial to define a class which stores a fixed-precision number and overload the +, -, *, etc. operators to make it as convenient as a built-in type, and put it in library. In my book, this is vastly superior to making such a type a built-in, because you can never satisfy everyone's requirements.

Re: Copilot regurgitating Quake code, including sweary comments

#274

Post by Quekid5 »

dangerbird2 wrote: post #241
gentleman11 wrote: post #94

Earlier quoted context omitted.

> The python example is using floats for currency. Dumb question, but what is the proper way to handle currency? Custom number objects? Strings for any number of decimal places?

Either a fixed-point decimal (i.e. an integer with the ones representing 1/100, 1/1000, etc. of a dollar, or a ratio type if you need arbitrary precision.

> ratio type if you need arbitrary precision.

This is the better default, so I'd ditch the qualifier, personally. At the very least when it comes to the persistent storage of monetary amounts. People often start out thinking that they won't need arbitrary precision until that one little requirement trickles into the backlog...

Arbitrary precision rationals handles all the artithmetic you could reasonably want to do with monetary amounts and it lets you decide where to round at display time (or when generating a final invoice or whatever), so there's no information loss.

Re: Copilot regurgitating Quake code, including sweary comments

#275

Post by thinkingemote »

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?

The most common example of this would probably be complaining about advertising whilst working for a business that depends on advertising to survive.

Ultimately it's a kind of Kafkaesque trap that modern living has us all in to a larger or lesser extent.

Re: Copilot regurgitating Quake code, including sweary comments

#276

Post by sydthrowaway »

saiojd wrote: post #149

Based on all the negative comments so far, and based on this website's aptitude at predicting the viability of a product, it really seems like Copilot is bound to be a success.

We're gonna Dropbox this thing all the way to the top!

Re: Copilot regurgitating Quake code, including sweary comments

#277

Post by buu700 »

joeyh wrote: post #258
buu700 wrote: post #181

Earlier quoted context omitted.

Makes sense. Maybe something like git-lfs/git-annex would be sufficient to address the linking issue, but it seems like the bigger concern is whether a court would accept this as valid attribution. In a sense it reminds me of the LavaBit stunt with the printed key.

I think a judge could be persuaded that a list of every known human does not constitute a valid attribution of the actual author, even though their name is on the list. The purpose of an attribution is to acknowledge the creator of the work, and such a list fails at that.

Makes sense. That's probably the best interpretation here. Any other decision would make attribution lists optional in general for all practical purposes.

Re: Copilot regurgitating Quake code, including sweary comments

#278

Post by advisedwang »

Thomashuet wrote: post #50

It seems like a very sensible answer from copilot since the prompt includes "Q_" which makes it obvious that the programmer is specifically looking for the Quake version of this function. To me it doesn't show that copilot will regurgitate existing code when I don't want it to, just that if I ask it to copy some famous existing code for me it will oblige.

The claim for AI systems like this is that it has actually learned something and is generating code from scratch. Oftentimes the authors will claim regurgitation is simply not possible, and this example shows that's a lie.

Many arguments on the benefits, legality and power of AI systems rely on this claim.

To turn around now and say it's OK to regurgitate in the right setting is to move the goalposts.

Re: Copilot regurgitating Quake code, including sweary comments

#279

Post by pjmlp »

adwn wrote: post #273
dralley wrote: post #204

Earlier quoted context omitted.

>[Modern] programming languages have decimal/rational data types This caveat is kind of funny, in light of COBOL having support for decimal / fixed precision data types baked directly into the language. It's not a problem with "non-modern" languages, it's a problem with C and many of its successors. That's precisely why many "non-modern" languages have stuck around so long. https://medium.com/the-technical-archaeolog…

> It's not a problem with "non-modern" languages, it's a problem with C and many of its successors. Not really. Any semi-decent modern language allows the creation of custom types which support the desired behavior and often some syntactic sugar (like operator overloading) to make their usage more natural. Take C++, for example, the archetypal "C successor": It's almost trivial to define a class which stores a fixed-…

It is also trivial to keep doing C mistakes with a C++ compiler, hence no matter how many ISO revisions it will still have, lack of safety due to C copy-paste compatibility will never be fixed.

Re: Copilot regurgitating Quake code, including sweary comments

#280

Post by 0xbadcafebee »

louthy wrote: post #5

This is utterly damning. I have already instructed my team that Copilot can never be used for our projects. Compromising the product because of unknowable license demands isn't acceptable in the professional world of software engineering. But if we put the licensing to one side for a moment... 1/ Everything I've seen it generate so far is 'imperative hell'. It is practically a 'boilerplate generator'. That might be u…

> programming languages should be an attempt to step up to a higher level of abstraction

Adding abstraction buries complexity. If all you do is keep adding more abstractions, you end up with an overcomplicated, inefficient mess. Which is part of why application sizes are so bloated today. People just keep adding layers, as long as they have room for more of them. Everything gets less efficient and definitely not better.

The right way to design better is to iterate on a core design until it cannot be any simpler. All of the essential complexity of software systems today comes from 40 year old conventions. We need a redesign, not more layers.

One example is version management. Most applications today can implement versioned functions and keep multiple versions in an application, and track dependencies between external applications. Make a simple DAG of the versions and let apps call the versions they were designed against, or express what versions are compatible with what, internally. This would make applications infinitely backwards-compatible.

The functionality exists right now in GNU Libc. You can literally do it today. But rather than do that, we stumble around replacing entire environments of specific versions of applications and dependencies, because we can't seem to move the entire industry forward to new ideas. Redesign is hard, adding layers is easy.

Post reply on HN