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

301–310 of 326 posts

Re: Did GitHub Copilot increase my productivity?

#301

Post by to11mtm »

Quothling wrote: post #151
marcus_holmes wrote: post #87

Years ago, over a decade ago now, I was a .Net developer. Microsoft introduced Entity Framework, their new way of handling data in .Net applications. Promises made, promises believed, we all used it. I was especially glad of Lazy Loading, where I didn't have to load data from the database into my memory structures; the system would do that automatically. I could write my code as if all my memory structures were popul…

> [0] Entity Framework has moved on a lot since then, and apparently now can be trusted to lazily load data To some degree. If you're using it for anything serious you're still going to help it along a lot. It's rather easy to do so, however, and I certainly wouldn't consider writing your own code as fast or easy as simply telling EF how you want it to do certain things. I'm not an overall fan of EF. I especially dis…

You might want to try Linq2Db, it is much closer to Diesel in how it works (More SQL DSL with parameter+reader mapper, less Unit-of-work ORM).

FWIW, it can actually work 'on top' of an Existing EF Core context+mappings (i.e. if you have an existing project and want to migrate, or just need the better feature-set for a specific case.) or you can get pretty close to 'yolo by convention' depending on case. In general though it's a lot less ceremony to start messing around.

Re: Did GitHub Copilot increase my productivity?

#302

Post by thegrim33 »

datavirtue wrote: post #266
marcus_holmes wrote: post #87

Years ago, over a decade ago now, I was a .Net developer. Microsoft introduced Entity Framework, their new way of handling data in .Net applications. Promises made, promises believed, we all used it. I was especially glad of Lazy Loading, where I didn't have to load data from the database into my memory structures; the system would do that automatically. I could write my code as if all my memory structures were popul…

I'm left wondering what AI everyone are using. I can prompt copilot and it gives me exactly what I need. Sure, if I barf out a lazy, half-baked prompt it yields a waste of time. My problem is running into it's limitations, mostly around resources. I have tried giving it larger tasks and it takes bloody forever. "Given this unstructured data, create CSV output for all platforms, with each line containing the manual, a…

Well, having AI transform some data into a certain CSV format is orders of magnitude simpler and more straightforward of a programming task than what I try to use it for.

A lot of the discrepancy between people's experiences is simply due to the fact there's there's a massive range of programming complexity/difficulty that people can be trying to apply AI to. If your programming is mostly lower complexity stuff, non-critical stuff, or simply defined stuff, it obviously works better.

I try to use AI when I get stuck on a hard problem/algorithm, hoping that it can provide an answer/solution to unblock me. But when I'm stuck the problem I'm facing is so complicated that there's no chance at all that AI is actually going to be able to help me with it. I see absolutely no point in using AI when I already know how to solve a problem, I just solve it. I only turn to it when I need help, and it can never help me.

Re: Did GitHub Copilot increase my productivity?

#303

Post by atonse »

arrowsmith wrote: post #133
nercury wrote: post #101

Earlier quoted context omitted.

Pardon me for the tangent (just a general comment not directed to OP). What I have learned over the years is that the only way to properly use ORM is as a fancy query tool. Build the query, fetch/update data, MOVE THE DATA to separate business objects. Don't leave ORM entities shared across the sea of objects! Phew, thanks, I got that off my chest.

I wouldn't have believed you until I moved from ActiveRecord (Rails's ORM) to Ecto (Elixir/Phoenix's data mapping library which is decidedly not an ORM.) It's a million times better and I'm never going back.

Ecto is hands down my favorite part of the elixir ecosystem.

It’s so elegant and the Lego blocks (query, schema, change set, repo) can be mixed and matched in different ways.

I’ve even used schemas and change sets to validate API requests and trivially provide very nice, clean, and specific errors, while getting perfectly typed structs when things are validated.

Re: Did GitHub Copilot increase my productivity?

#305

Post by marcus_holmes »

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 think the core thing that ORMs do is create a 1:1 mapping between the data structures in the database (that are, or should be, optimised for storage) and the data structures in the application (that are, or should be, optimised for the application business logic).

ORMs create this false equivalence (and in this sense, so does Django's admin interface despite using tuples instead of classes). I can see the sense of this, vaguely, for an admin interface, but it's still a false equivalence.

Re: Did GitHub Copilot increase my productivity?

#306

Post by nercury »

thaumasiotes wrote: post #234
nercury wrote: post #123

Earlier quoted context omitted.

Yes, I would not put it just anywhere. But I have few rules about ORMs: - Proper DB design first. You should be able to remove the ORM and DB should still function as intended. This means application-side cascade operations or application-side inheritance is banned. - No entities with magical collections pointing to each other. In other words, no n to n relations handled by ORM layer. Create in-between table, for god…

> No entities with magical collections pointing to each other. In other words, no n to n relations handled by ORM layer. Create in-between table, for gods sake. Otherwise it becomes incredibly confusing and barely maintainable. So, I have a database that looks like this. My method was to lay out the database myself, by hand, and then use EF's facility to generate EF code from an existing database. The bridge table wa…

This is more of a preference for bridge to be visible in application. Also the bridge may seem simple at first, but it also may gain associated data, like created_at, order, etc.

Re: Did GitHub Copilot increase my productivity?

#307

Post by serpix »

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…

I use combinations of the two. Sometimes it really is worth it to write a comment on what one is trying to achieve and just let it autocomplete the entire thing. And sometimes just for autocompleting a 'for loop' - a small block of code that one already has in their minds.

Re: Did GitHub Copilot increase my productivity?

#308

Post by DanielHB »

noduerme wrote: post #112
nercury wrote: post #101

Earlier quoted context omitted.

Pardon me for the tangent (just a general comment not directed to OP). What I have learned over the years is that the only way to properly use ORM is as a fancy query tool. Build the query, fetch/update data, MOVE THE DATA to separate business objects. Don't leave ORM entities shared across the sea of objects! Phew, thanks, I got that off my chest.

adding an off the shelf ORM layer creates so much more opacity and tech debt than writing queries I don't understand why anyone would willingly put one into their stack. Sure, they're neat although I don't even know if they save time. There's something very satisfying about well-crafted queries. And is it ever really well crafted if you can't tweak them to improve their their execution plan? I've never had a client o…

Most queries are pretty trivial, ORMs are great for 90% of queries. As long as you don't try to bend the ORM query system to do very complicated queries it is fine. Most (all?) ORMs allow raw queries as well so you can mix both.

On top of that most ORMs have migrations, connection management, transaction management, schema management and type-generation built-in.

Some ORMs have inherently bad design choices though, like lazy loading or implicit transaction sharing between different parts of the code. Most modern ORMs don't really have that stuff anymore.

Re: Did GitHub Copilot increase my productivity?

#309

Post by cultofmetatron »

arrowsmith wrote: post #243
cultofmetatron wrote: post #223

Earlier quoted context omitted.

same, I wish more libraries would go the ecto design route. my ecto queries map pretty close to 1:1 with the sql counterpart. no guessing what the output is going to look like. I spend my time debugging the query and not trying to get the orm to output he query I want.

Yeah, I hear some people say that they find Ecto.Query confusing, and I think it's because they never learned SQL properly. That's understandable because it's possible to use something like ActiveRecord for years without ever learning to write even a simple SQL query. But if you have a good grasp of SQL then Ecto.Query is trivial to learn - it's basically just SQL in Elixir syntax.

> it's basically just SQL in Elixir syntax.

its sql in elixir syntax with a bunch of QOL improvements.

for one thing, I can seperate my subqueries into separate variables

``` sub_q = from(l in Like) |> where([l], l.user_id == ^user_id) |> select([l], %{ user_id: l.user_id, likes_count: count(l.id) }) |> group_by([l], l.user_id)

main_query = from(u in User) |> join(:left, [u], likes_count in ^subquery(sub_q), on: likes_count.user_id == u.id, as: :likes_count) |> select([u, likes_count: l], %{ name: u.name, likes: l.likes_count, }) |> where([u], u.id == ^user_id)

user = main_query |> Repo.one()

```

Being able to think directly in sql lets you perform optimal queries once you understand sql. and imho, this much cleaner than tha equivalen sql to write. it also takes care of input sanatization and bindings.

Re: Did GitHub Copilot increase my productivity?

#310

Post by munksbeer »

AlexandrB wrote: post #263
couchand wrote: post #207

Earlier quoted context omitted.

Test code is code. It's as much of a burden as every other piece of code you are troubled with, so you must make it count. If you're finding it repetitive and formulaic, take that opportunity to identify the next refactoring. Just churning out more near copies is not a good answer.

The problem with refactoring test code is twofold: 1. It can make it harder to see what's actually being tested if there are too many layers of abstraction in the test. 2. Complex test code can have significant bugs of its own that can result in false passes. What tests the test code? Thus I generally see repetitive or copy/pasted test code as a necessary evil a lot of the time.

Absolutely this! I was very guilty of over complicating test code to use abtractions and reduce boilerplate, but it certainly resulted in code which you could not always tell what was being tested. And, you'd result in nonsensical tests when the next developer added tests but didn't look deeply to see what the abstractions were doing.

I now find it is best to be very explicit in the individual test code about what the conditions are of that specific test.

Post reply on HN