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

Did GitHub Copilot increase my productivity?

trace.yshui.dev

Post reply on HN
Print view View original

281–290 of 326 posts

Re: Did GitHub Copilot increase my productivity?

#281

Post by freedomben »

randomdata wrote: post #268
DangitBobby wrote: post #267

Earlier quoted context omitted.

What should I call a program that generates SQL, executes it, and stores the result in a tuple, object, or whatever data structure in the programming language that I'm using? Does it magically stop being an ORM the second I use a tuple instead of a class instance, or is it now an ORM plus another nameless type of program? Are tuples also objects?

Whatever you want. It's your life. Traditionally, though, SQL generation was known as query building. The query was executed via database engine or database driver, depending on the particulars. ORM, as the name originally implied, was the step that converted the relations into structured objects (and vice versa). So, yes, technically if you maintain your data as tuples end to end you are not utilizing ORM. Lastly, t…

I agree with you, but I do think there's a little fuzziness between full-blown ORM and a tuple-populating query builder in some cases. For example Ecto, which can have understanding of the table schema and populate a struct with the data. It's just a struct though, not an object. There's no functions or methods on it, it's basically just a tuple with a little more organization.

Re: Did GitHub Copilot increase my productivity?

#282

Post by thaumasiotes »

echelon wrote: post #271
thaumasiotes wrote: post #216

Earlier quoted context omitted.

The balloon is a different shape from shot to shot, and - much worse - in a few of the shots it appears to be hovering in front of the rest of the image rather than occupying the space where Air Head's neck should be. Is it better than I could do? Yep. Is it failing a bar that any human would pass? Yep. Is it better than relevant artists? Nope. But it is cheaper.

Literally everyone in this space is working on controllability. The cherry picked issue you cited has hundreds of the best minds tackling it as we speak. This is the worst it will ever look. It's only going to improve from here. Compare that to the early days of silent film. The profess with Gen AI is astounding. We're going to have Disney/Pixar and Scorsese outputs by the end of the decade. (I'd be willing to wager…

> The cherry picked issue you cited has hundreds of the best minds tackling it as we speak.

Did you mean to respond to my other, nearby comment? The issue I cite above isn't cherry-picked in any sense; it's a big, glaring problem with what was cited as an example of "good work". If someone's head is a balloon, the balloon should occupy the same position in 3D space as the head would.

> Compare that to the early days of silent film.

This is an interesting comparison. I don't think it really works. Early silent films were aware of what could and couldn't be done in the medium; there aren't any that rely on a nonexistent soundtrack. Generative AI stuff doesn't seem to be very concerned with "what kinds of things can we do well?". Instead, they're attempting everything, almost none of it is being done particularly well, and there are theoretical arguments over whether it makes sense to try to improve on individual tasks.

Re: Did GitHub Copilot increase my productivity?

#283

Post by pradn »

yreg wrote: post #46
muglug wrote: post #29

GitHub touts a 55% improvement in coding speed based on a study conducted in-house that tested the participants’ ability to paste a pre-written prompt and then check the output: https://github.blog/2022-09-07-research-quantifying-github-c... The effectiveness of a Copilot-like tool trialed at FB showed that 8% of code contributed by participants was sourced from suggestions, but the latter study made no promise about…

My personal feeling is that utilising LLM assistance often isn't faster, but it can take less "stamina", tiring me less.

I find it far more tiring because I don't have "micro-breaks" where I'm slowly typing code. I just have to be in a serious "check the logic" mode for a longer period of time.

It also makes it a lot easier for juniors to chuck random code at seniors for review.

Re: Did GitHub Copilot increase my productivity?

#284

Post by tucnak »

mhuffman wrote: post #225
tucnak wrote: post #134

Earlier quoted context omitted.

Deep learning is the most important thing to happen to philosophy since Socrates / Wittgenstein.

I would be very interested in you providing an example of Deep Learning offering more cultural or historical impact than Socrates / Wittgenstein.

I mean, already ChatGPT alone has made more cultural and historical impact per capita than the aforementioned gentlemen, simply because nobody cares about philosophy. But that was never my point. My point is: you can think of uncle Witt kind of like "postmodern" twist on Socrates, i.e. they're both effectively talking about the same thing: determining optimal form for computing language. Wittgenstein had made considerable progress here, i.e. language games, and now we finally get means to literally compute these. To me it's absolutely clear; this is the most important thing to happen in philosophy.

Re: Did GitHub Copilot increase my productivity?

#285

Post by theshrike79 »

dathinab wrote: post #227
theshrike79 wrote: post #114

Earlier quoted context omitted.

With VSCode at least you can say @workspace to Copilot and it'll take it into account. No idea if it feeds all of the code to the LLM or just parts, but it's pretty good at interpreting what the code does

It guaranteed can't have all of your code in the LLM context, or even all of your file (in case of longer, through not even quite long files). Through it could do stuff like go through your repository(ies) and generate embedding for sections of it and then have a vector database + retrieval argumented generation (RAG) system.

Yea, that's the way they're going based on the low-memory models they're building.

Basically all the LLM needs to do is translate human writing to some format that a "normal" service can use. That can then leverage the existing spotlight system that's pretty decent at searching stuff on the phone anyway.

Then it'll report it back to the LLM which translates whatever format back to something humans can process.

Basically "less shit Siri"

Re: Did GitHub Copilot increase my productivity?

#286

Post by mucle6 »

alecthomas wrote: post #142
serpix wrote: post #86

Earlier quoted context omitted.

This is how I've used it: "I want to write a function that reduces a map of customer data to a list of their phone numbers from their primary addresses only or contact address if there is no primary address" and then you look at the resulting flatmap, filter, reduce blob of AI generated code and figure out if what it does is correct for about a minute.

This was an illuminating comment because I think I finally understand why people have wildly varying experiences with CoPilot. I think if you regularly use CoPilot to write entire functions or use its prompt mode, you will spend more time verifying its output is accurate than it would save writing the code manually. If instead, you use it iteratively via autocomplete to write small fragments of code, a line or two at…

This makes sense. I just can't imagine how most people hate the autocomplete. If you like a suggestion you hit tab. If not you keep typing.

Re: Did GitHub Copilot increase my productivity?

#287

Post by PeterisP »

DangitBobby wrote: post #259
blksv wrote: post #147

Earlier quoted context omitted.

Rows are tuples, not objects, and treated as such throughout the code. Only the needed data is selected in the form most appropriate to the task at hand, constructed in a hand-written sql query, maybe even taylored to the DB/task specifics. Inserts/updates are also specific to the task, appropriately grouped, and also performed using plain sql. Data pipelines are directly visible in the code, all DB accesses are expl…

Maybe we need to use a different acronym than ORM, because to me the thing we can all agree we need is code that emits SQL. If you can't agree that projects need generated SQL because SQL is dog water for composition, then we can't really agree on anything.

I'd argue that "code that emits SQL" is never an inherent need but a possible development time-saver - we need code that emits SQL in those cases (and only those cases) where it saves a meaningful amount of development time compared to just writing the SQL.

Re: Did GitHub Copilot increase my productivity?

#289

Post by yshui »

amanzi wrote: post #43

I feel like this bit is important for this discussion: "...I do not use Copilot for my day job. I use it for my own projects only..." My guess is the people that don't use Copilot because they don't trust it, or don't like the code it produces, are probably trying to use it in a professional scenario where they have strict coding standards. For hobbyist use or side-projects, Copilot is an incredible time saver. I use…

Author here. I probably should have stated this more explicitly in the article, but my main concern with using it for day job is copyright. I don't want to accidentally commit copyrighted code into the codebase, and I work for an open source project.

Re: Did GitHub Copilot increase my productivity?

#290

Post by blksv »

DangitBobby wrote: post #259
blksv wrote: post #147

Earlier quoted context omitted.

Rows are tuples, not objects, and treated as such throughout the code. Only the needed data is selected in the form most appropriate to the task at hand, constructed in a hand-written sql query, maybe even taylored to the DB/task specifics. Inserts/updates are also specific to the task, appropriately grouped, and also performed using plain sql. Data pipelines are directly visible in the code, all DB accesses are expl…

Maybe we need to use a different acronym than ORM, because to me the thing we can all agree we need is code that emits SQL. If you can't agree that projects need generated SQL because SQL is dog water for composition, then we can't really agree on anything.

Probably so: I can't agree with that particular inference.

1. Very often we need generated SQL because writing SQL for primitive CRUD operations is hell tedious and error-prone (as well as writing UI forms connected to these CRUD endpoints, so I prefer to generate them too).

2. Structured Query Language being very poorly structured is indeed a huge resource drain when developing and maintaining complex queries. PRQL and the like try to address this, but that's an entirely different level of abstraction.

3. Unfortunately, when efficiency matters we have to resort to writing hand-optimized SQL. And this usually happens exactly when we terribly need a well-composing query language.

Post reply on HN