Hacker News new | ask | show | jobs
by happyhardcore 1463 days ago
I've found copilot invaluable for throwing together quick scripts, especially in languages I don't quite understand. Writing e.g. a bash script, and being able to add a comment saying

    # Print an error message in red and exit if this program returns an error
and have it print out

    if ! some_program
    then
        echo -e "\e[31msome_program failed\e[0m"
        exit 1
    fi
makes it so much quicker to cobble together something that works without having to context switch and go Google something. That being said, I've found when writing more complex code it has a real tendency to introduce subtle bugs that can really catch you out if you're not paying attention.

Purely from the amount of time I've saved I'd say it's well worth the $10/mo for my employer (it only has to save a few minutes a day to be worthwhile). Very excited to see how they improve it in the future!

6 comments

I've found when writing more complex code it has a real tendency to introduce subtle bugs that can really catch you out if you're not paying attention.

Yea, that is basically my experience as well. On balance I feel I wasted about as much time debugging broken copilot code as I've saved from using it.

I totally agree. If you code professionally in a stack where copilot perform well, 10 usd/month is a steal. Assuming you are just 5% more productive with copilot, that would easily translate into hundreds of dollars of savings.

It's for the hobbyists that it's painful. Adding another 10 usd subscriptions might be too much for your budget, especially if you only code occasionally.

It would have been nice of them to introduce a free tier where you could use copilot for a few hours a month for free.

This is unfortunate, because my experience has been that it's far more harmful than helpful when I'm working in stacks/techs that I am comfortable and experienced in- the ones I use professionally-, but extremely useful when I'm working in an unfamiliar language or stack as I often do for hobby projects.
I guess that makes sense. It's mostly useful when working on mundane tasks on popular stacks. Experts working on non-trivial use-cases won't see much benefits.

Personally, I'm not a in a coding position anymore and only code occasionally on stacks I'm mostly unfamiliar with: copilot is a godsend as it saves me from googling every other lines of code to figure out which api calls I'm suppose to do to accomplish the task at end.

I see it as a stackoverflow on steroids.

Even if I don't use it much, I guess I'll have to pony up the 10 usd because I would not want to go back to googling basic syntax for everything when I'm coding something.

Do you think you learn as well or deeply?

Is the act of finding a help for learning?

Do you retain as much? Do you need to? Is that important?

I hope this whole thing ends up like a space saving tool like Google did. I don't need to memorise that API because I can Google the docs. Now maybe that goes a level higher.

Is copilot then not teaching you bad habits that you can't see due to lack of familiarity? Is that a good thing?

The idea of learning via copilot, producing poor code and having copilot learn from that code ... the whole feedback loop ... Is worrisome.

> far more harmful than helpful when I'm working in stacks/techs that I am comfortable and experienced in... but extremely useful when I'm working in an unfamiliar language

Ignorance is bliss.

This smells a lot like a Gell-Mann amnesia effect.
Ha I don't think it's totally that, but it may well be part of it!

I think the biggest thing is that when working in tech I'm unfamiliar with it's extremely helpful to get some sort of skeleton in place, even if it's wrong in some way. I'm going to have to go slowly and evaluate it either way, so doesn't really matter if it's got problems or is less than ideal. What I would do otherwise is just go copy something from StackOveflow and then comb over it to adapt to my needs. Copilot is more or less just doing the same thing, but faster.

When I'm working in a stack I know well, I can quickly put down the code I need and it will generally be pretty good. Copilot can do it faster, but it gets things wrong a lot more often than I do. Since fixing something wrong is a LOT slower than me getting it right the first time, it ends up being more trouble than it's worth.

Maybe they can replace you with copilot and an unexperienced cheaper user.
Honestly, that’s the hope. Putting together well-solved combinations of computer functionality ought to become less-skilled work as technology progresses.
That's been the objective of programming languages for 50 years. It hasn't happened yet, because the essential complexity of programming problems isn't in writing the code.
I think it definitely has happened. We're creating more things, for cheaper.

We're also creating more complex things, that costs more money.

anecdotally, this is where the famous lack of modern skills comes from in engineering culture. If you keep doing the same things you've been doing, you'll look around one day and see that everyone has moved on.

The market for simple SMB websites is a great example. This went from custom HTML+webservices, to Wordpress, and now to WIX/shopify/square. I'd bet the market for SMB marketing will similarly move to near plug+play google/FB offerings.

However if you started out making websites in 1993, then there are a vast array of products and services one could move into over the last 3 decades.

We have just moved up the complexity curve.

It's the same with doctors, lawyers, everything.

If law - the human language equivalent of programming - hasn’t gotten simpler in past thousands of years as new abstractions and complications have arisen, I hold no hope for programming.
Surely the human language equivalent of programming is recipes and other types of written instructions. Law is far more abstract and subjective than programming.
Law is opposed to these sorts of changes due to the business model of the law firm. In the law firm world billable hours are king. Automation reduces billable hours. No law firm wants to do that.
I think this really depends on what kind of firm you're talking about. You could make the same case for contractors i.e. "billable hours are king". Take the example where you need to paint a house. You could hire someone off the street who does it with a paintbrush and rollers or hire a pro with a sprayer and prep knowledge to do it in 1/4 the time and with 10x the quality.

In this context automation could be a tool that a law firm uses to enhance the quality of their product. Personally, I would pay more for a tech-savvy law firm that embraces automation, not less.

A lot of contractors in painting/drywall do piecework rather than hourly. My roommate has been a drywall taper for 20+ years. When he quotes a job it’s a flat rate and then he tries to finish as fast as possible by using his best tools to speed up the job. On the other hand, if someone hires him on an hourly basis he puts away those fancy tools and does a lot more manual work, getting the job done slowly.

His rationale: why put wear and tear on his expensive tools if it’s just going to reduce his income in the end? Needless to say he prefers piecework because he likes to move from one job to the next as quickly as he can. He makes a lot more money that way.

I think it has more to do with having an adversarial law system. It doesn’t matter what new tool you come up with in the arms race. Your competitor will soon have it as well.
Law is different in most places because the “execution model” isn’t intended to be a process, but is instead a mediated dispute.
Maybe they will converge, and all programs will be written in legalese and interpreted by Copilot.
A'la Ethereum's smart contracts?

Code isn't flexible enough to work for laymen. It feels like you need to be a developer and a lawyer to make a smart contract work as intended.

Maybe that works against my earlier premise, but I don't think that this is the way we want to go.

Or maybe they’ll replace a junior dev with copilot and make the more experienced folks spend more time “fixing” broken copilot code.
Weird that it prints the error to stdout. I mean not that surprising really, I'd just expect error->stderr to be a pretty low-hanging association
I've seen many many scripts that ignore STDERR and just print everything normally.
Yes, but that's a perfect illustration for one of copilot's essential flaws: "a lot of flies eat poop" (side note: is that actually a saying? Asking because in German it is, and it fits perfectly here).

A lot of code is of mediocre quality. An ML service that learns from huge amounts of code without an ability to tell "good" code from "bad" code will only ever be able to produce mediocre code, at best.

> side note: is that actually a saying?

I've never heard it before but i'll be using it now :)

It's saying "just because it's popular doesn't mean it's good" and it's doing it quite well.
Which may still be of value if you know and can recognize mediocre code.

Some code is like a giant pile of dirt; you need someone to pile it up and then you can go in and clean up the edges and make it "good" whereas other code is entirely delicate all the way through.

The big question is how much is each one and can it help. I suspect it helps for many, but those who know enough to recognize where it can flaw will have an advantage.

But newer programmers may never really "learn" the code the way the older ones do, as they'll just let the computer do the basics.

So, Copilot is a _junior_ developer. Isn't that a matter of just managing expectations?
If you don’t quite understand the language, how do you know it doesn’t also have subtle bugs?
Holy **. This is exactly the kind of use case ML code generation should NOT be used for. If you don't even understand a language you will probably not be able to debug subtle bugs that are introduced, especially in something like bash. Please don't do this for anything that touches prod.