Comment by lolinder | Hacker News Reader

Comment by lolinder | Hacker News Reader

I've stopped trying to use GPTs for complex tasks like what you describe, but I find them to be invaluable for getting a lot of grunt work done on my hobby projects.

As a concrete example: GitHub Copilot has been absolutely life-changing for working on hobby programming language projects. Building a parser by hand consists of writing many small, repetitive functions that use a tiny library of helper functions to recursively process tokens. A lot of people end up leaning on parser generators, but I've never found one that isn't both bloated and bad at error handling.

This is where GitHub Copilot comes in—I write the grammar out in a markdown file that I keep open, build the AST data structure, then write the first few rules to give Copilot a bit of context on how I want to use the helper functions I built. From there I can just name functions and run Copilot and it fills in the rest of the parser.

This is just one example of the kind of task that I find GPTs to be very good at—tasks that necessarily have a lot of repetition but don't have a lot of opportunities for abstraction. Another one that is perhaps more common is unit testing—after giving Copilot one example to go off of, it can generate subsequent unit tests just from the name of the test.

Is it essential? No. But it sure saves a lot of typing, and is actually less likely than I am to make a silly mistake in these repetitive cases.

Agreed, GitHub Copilot is fantastic if you give it something to work off of and outsource repetitive tasks to it. You still need to babysit it a little bit (it made a very subtle bug once that took a while to figure out), but it does a great job of generating code based on the other things you've been doing. It's a great little assistant to make coding less tedious.

On the other hand, if you are writing repetitive code - are you missing an easy abstraction? Or if not, some easy code gen? If I find myself starting to write repetitive code It usually means I did something wrong.

This has more to do with the fact that copilot by nature is additive and not editing your code. There was a recent report about how code quality is dropping in codebases because of the repetitive code being introduced by copilot.

The next evolution as you are saying would be to detect if its a repetitive code and modularise it or refactor it.

You can do this today with the VS Code extension. There’s a context menu for copilot to do things like “explain this code”. I asked it to make my current class more DRY and it refactored validation and parsing for a dozen or so arguments. It had one minor misunderstanding of my intent which I fixed by hand.

This is why I specifically identified that there there are cases where there is no reasonable abstraction. DRY has become so much of a mantra in the industry that it's taken for granted that any repetition must be unnecessary, but there are times where that's just wrong.

The first example I gave is parsers—even after you've factored out as many helper functions as you can, you'll eventually hit a floor where you have to use those helper functions and piece the results together. That floor is necessarily repetitive—you end up with a bunch of 5 to 10 line functions calling the abstractions and feeding the results together.

Unit tests is another example: I find that when people get too DRY in unit tests it just ends up obfuscating what the test is testing and makes changing the program later harder. Same as with parsing, there is a floor for how much abstraction is reasonable and once you have hit that floor you still have to go through the rote repetition of stringing functions together and asserting things about the results.

With a parser you actually have to do this, but with unit tests people will as often as not give up on the tedium and just not cover all the edge cases. Copilot enables developers to stop writing the repetitive code and spend their unit testing time thinking of edge cases.

Copilot is the easy code gen in this case. It's even surprisingly good at Rust macros.

Yes! It's surprisingly good at Rust in general, and does a better job with macros than intellisense does.

This mentality has been taken entirely too far in software development. People think if they have to write the same single line more than once then they are doing it wrong. That could not be further from the truth.

Unless you find yourself writing the exact block of code, without any modifications, 3 or more times it’s better to have the “duplicated” code. Until you hit 3+ times you are just guessing at future usage and in my experience developers, myself included, are terrible at guessing the future.

I’ve watched “DRY” code turn into a monster when someone, like myself, tries to force a bunch of use cases into a single flow in order to be DRY. You end up with confusing code that’s trying to do too many things in a single function/block littered with if/else such that stepping through it (in your head) is complicated and error-prone.

I regularly ask the developers who work under me to first duplicate the code and use it a few different times before going back and deciding “can this be made generic without standing on our heads?”.

Recently I had to deal with an item list component that was made to display 2 vastly different types of data. The component was responsible for rendering out the items themselves since they had some UI similarities. The code is nightmare with a ton of input properties to tweak the display/functionality based on the type of item you want to render out. All in the name of DRY, the “well these look similar so we better abstract this and use it in both places”.

When I was a younger developer I thought this way and wrote code this way. It’s unmaintainable, entirely too “clever” (that’s a bad thing), and hard to reason about. Nowadays I value readability and ease of understanding over “DRY for DRY’s sake”.

In case you're not aware of it the name for what you like is WET ("Write everything twice/thrice") rather than DRY.

My experience exactly. I think the DRK (Don’t Repeat Knowledge) acronym (not my invention) is a better target. Too often people mistake similar structures of code as “repetition”.

Instead, if you focus on not repeating the important “knowledge” of your code (algorithms, business rules, etc), it’s easier to avoid the trap of over-abstracting.

Agreed. I’m fine if you want to extract sub-parts of the function “generateId”, “hashX”, “lookupY” and have 2 functions that call 2 out of 3 (different 2) of the shared helpers/functions, just don’t create a single function that if/else’s the 2 paths.

Better put, if you have logic A, B, C, D and 2 code paths:

Code path 1: ABD

Code path 2: ACD

Then you should have:

Function 1: ABD

Function 2: ACD

Not

MegaFunction: A (if X then B) (if !X then C) D

Too many people see a common “A” and “D” and rush to have a common function that if/else’s the B/C.

Reply on news.ycombinator.com