Hacker News Reader

Comment by inimino | Hacker News Reader

I'm amazed to see how positive the overall response is to this idea. Almost as if programmers think that writing programs is the worst part of the job and ready to be automated away.

As someone more aligned with the Dijkstra perspective, this seems to me like one of the single worst ideas I've ever seen in this domain.

We already have IDEs and other tools leading to an increase in boilerplate and the acceptance of it because they make it easier to manage. I can only imagine what kinds of codebases a product like this could lead to. Someone will produce 5000 lines of code in a day for a new feature, but only read 2000 of those lines. Folks that still expect you to only check in code you understand and can explain will become a minority.

I wonder how long it will be until someone sets up the rest of the feedback loop and starts putting up github projects made of nothing but code from this tool, and it can start to feed on itself.

Cargo-cult programming has always been a problem, but now we're explicitly building tools for it.

View on HN

I mean you say this, but you and most likely the majority of programmers rely on dozens of repositories, packages and libraries with likely zero deep understanding of it (and at the very least haven't read the source code of ) so I don't really understand the difference here.

The advantage of something like this is that instead of having to go to stack overflow or any number of reference sites and copy pasta it can just happen automatically without me having to leave my IDE.

The enjoyable part of programming for me is not typing the Ajax post boilerplate bullcrap for the millionth time, it's the high-level design and abstract reasoning.

I really wonder who those folks copy-pasting from Stack Overflow all day are. I only rarely find pieces of code that I can copy-paste. Typically Stack Overflow only gives me an idea of how to solve something, but incorporating that idea into my code base is still not trivial.

A few weeks ago someone on a call said "we all know that programming is mostly copy and pasting anyway" A few people laughed, but I said that if I catch myself copy and pasting then I know that something is very wrong. It was kind of awkward, but I didn't like my job being trivialized by people who never really did it.

It would be like if I said plumbing or auto repair is just watching youtube videos and going to lowes. Just because I've managed to do a few simple things, doesn't mean I'm in a position to belittle an entire profession.

That said, I am also shocked by how many full time developers don't take the time to understand their own code. Let alone the libraries they use.

> That said, I am also shocked by how many full time developers don't take the time to understand their own code. Let alone the libraries they use.

Me too, then I understood that code and programming is commoditized. As long as it works and looks pretty on the outside and it can be sold, it's fair game.

"There'll be bugs anyway, we can solve these problems somehow" they probably think.

Heck even containers and K8S is promoted with "Developers are unreliable in documenting what they've done. Let's make things immutable so, they can't monkey around on running systems, and make undocumented changes" motto.

I still run perf on my code and look for IPC and cache trashing ratio numbers and try to optimize things, thinking "How can I make this more efficient so it can run faster on this". I don't regret that.

> A few weeks ago someone on a call said "we all know that programming is mostly copy and pasting anyway"

That's a dog whistle to find a better company/location.

Some people consider using stack as a heavy inspiration to be equivalent to "copy and pasting." It's linguistic shorthand really.

I am one of those. Unless it’s a few lines of standard library calls for the behavior I’m seeking, If I am copy and pasting a function over its as a template.

I then modify the majority of the answer to fit any special criteria outside of the general case I asked, or more frequently, modify the code beyond the minimum viable answer to fit in the test suite/logging framework/performance monitoring/etc that is involved in my platform

Still call it copy and pasting in casual conversation even if there’s not a single line that’s recognizable between where I started in stack overflow vs where I ended up

> That said, I am also shocked by how many full time developers don't take the time to understand their own code. Let alone the libraries they use.

Own code would be bad but libraries? That's kinda the idea of an abstraction layer.

I always look into the internals of libraries I use, it's usually easier, and faster than reading the documentation. Sure, there are some libraries that so advanced that it makes this difficult, but you should still know what it's doing, and how the code is organized.

The idea of an abstraction layer is to make it easier to read and write code that is at a different layer. Many of us write our own abstractions, it's not because we don't understand what its doing.

>That said, I am also shocked by how many full time developers don't take the time to understand their own code. Let alone the libraries they use.

So many STLs are fucking unreadable. Golang's is the only one where I've actually enjoyed it a bit.

> I really wonder who those folks copy-pasting from Stack Overflow all day are.

I can think about people who can do this happily. Some of them are professional programmers. Some are self-taught. Some have CS education. Seriously.

OTOH, I'm similar to you. I either re-use my own snippets or read SO or similar sites to get an idea generally how a problem is solved and adapt it to my code unless I find the concept I'm looking for inside the language docs or books I have.

Yes, I'm a RTFM type of programmer.

I had a colleague who once tried to copy-paste a Scala snippet into Python code and came to complain that it doesn't work. We're no longer colleagues.

Yep. And now imagine these people with Github Copilot in their arsenal. God help us all.

Well, at least Copilot will bring some kind of "intelligence" to the party.

There is certainly a balance. When I want to implement feature X a client has requested but I have to deal with home grown database abstraction layers and custom AJAX API structures - I get the feeling that a third party library probably does it better and has more eyes on the code than exist at my company.

That said I would probably not look to a third party library to just to simple data transformation stuff. Probably the only thing I do copy almost verbatim from SO are things like Awk/Sed commands that are easy/low risk to test but would take hours to derive myself.

Thank you! I've never understood this meme about copy-pasting. I honestly rarely end up using SO and when I do, I almost never copy paste from there. It's not because it's some kind of weird principle I have - I will copy paste if I think it makes sense - it's just rare that I want the exact thing they have written there (it's in JS and I'm using TS, it's using another library than I am, etc) and generally I'm looking for information rather than code.

Importing an external, tested, reliable dependency is completely different from anonymous non-checked untested code in your repository committed by someone who did not even read it.

Check out the memoize example. That fails as soon as you pass anything non-primitive but there’s no one documenting that.

> anonymous non-checked untested code

What? It's not anonymous, it's still committed by a dev. It can be non-checked and untested, that's true. But it's not any less untested than any other code. If you choose not to write tests for your code, this won't change anything.

The only issue I see with this is it being potentially unchecked. And the solution to that is reading all the code you commit, even though it's generated by AI.

It's about affordances. As presented, this tool streamlines copy-pasting random snippets. The easier something is, the more people do it.

Testing doesn't even enter the picture here, we're at the level of automating the stereotypical StackOverflow-driven development - except with SO, you at least get some context, there's a discussion, competing solutions, code gets some corrections. Here? You get a black-box oracle divining code snippets from function names and comments.

> the solution to that is reading all the code you commit, even though it's generated by AI

Relying on programmer discipline doesn't scale. Also, in my experience, copy-pasting a snippet and then checking it for subtle bugs is harder than just reading it, getting the gist of it, and writing it yourself.

> Programmer discipline doesn’t scale

Thank you for putting this so eloquently. This has basically been the sole tenet of my programming philosophy for several years, but I’ve never been able to put it into words before.

> As presented, this tool streamlines copy-pasting random snippets.

It synthesizes new code based on a corpus of existing code.

Yes. Given how it does it, this makes it even more dangerous than if it was just trying to find a matching preexisting snippet.

>Tests without the toil. Tests are the backbone of any robust software engineering project. Import a unit test package, and let GitHub Copilot suggest tests that match your implementation code.

It looks to me like they're suggesting you use Copilot to write the tests.

Who wrote that snippet? Who knows? That’s anonymous. Just because I committed it it doesn’t mean I wrote it. There’s no link to the source, so it’s anonymous, even if committed by me. This is 100% equivalent to copying a whole function from StackOverflow but without placing a link to the answer for context.

A programmer who commits untested sloppy code of their own writing, will do it regardless of having access to such a service. Nothing will make me commit the generated code without testing it. I think this tool could take care of the boilerplate and the rest will still be on the programmer. At least in the near future.

anonymous non-checked untested code is problematic in all cases. This doesn't change that.

You don't see the difference between relying on a few battle-hardened libraries, and copy-pasting into your own code some mishmash of code that looked similar that other people wrote and is probably something like what a machine learning model thought you probably meant? Maybe we're in worse shape then I thought.

> The advantage [...] without me having to leave my IDE.

You're arguing for the convenience, my point was that that convenience creates a moral hazard, or if you prefer, a perverse incentive, to increase the number of lines of code, amount of boilerplate, code duplication, and to accept horrible, programmer-hostile interfaces because you have tied yourself to a tool that is needed to make them usable.

> Ajax post boilerplate

This is an argument for choosing the most appropriate abstractions. The problem with boilerplate isn't that you have to type it, it's that it makes the code worse: longer, almost certainly buggier, harder to read and understand, and probably even slower to compile and run. You could have made an editor macro 20 years ago to solve the typing boilerplate problem, but it wasn't the best answer then and it isn't now.

> The advantage of something like this is that instead of having to go to stack overflow or any number of reference sites and copy pasta it can just happen automatically without me having to leave my IDE.

In the examples, I wish the auto-generated code came with comments or an explanation like SO does. The code I need help with the most is the code that's a stretch for me to write without Googling. The code I can write in my sleep I'd rather just write without a tool like this.

> I mean you say this, but you and most likely the majority of programmers rely on dozens of repositories, packages and libraries with likely zero deep understanding of it (and at the very least haven't read the source code of ) so I don't really understand the difference here.

I spend a probably half my coding time testing and digging into those libraries because I don't understand them and because they cause performance issues because nobody on the team understands them sufficiently to make their "high level design and abstract reasoning" accurate.

One problem with the current world of programming tools is that there's no good way to know which libraries are suitable for use when correctness and performance and reliability really matters, and which are only really meant for less rigorous projects.

> you and most likely the majority of programmers rely on dozens of repositories, packages and libraries with likely zero deep understanding of it

Perhaps AI should work on simplifying the existing stack first, without breaking the functionality. What about that?

if you are typing out boilerplate you should look to abstract it away

Oh god please don't do this indiscriminately. If you're typing out boilerplate, document it and add a generator for it. I've been bitten probably hundreds of times by bad abstractions created to save some keystrokes that turned 50 lines of boring easily readable code into an ungrokable dense mess.

"Okay, so you pass the function a lambda. And the input parameter to that lambda is another function that itself consumes a list of lambdas. And this is so that you don't have to init and fill in a few dictionaries OR because you might need to otherwise use an if-statement."

I like abstractions as much as the next person, but oftentimes you can just make due with the exact thing.

What do you mean "add a generator for it"? Do you mean something like a templating for source code, like the C pre-processor?

I think there is a pro and a con to that approach.

The pro is that there is a meaningful and familiar intermediate representation --- the output of the C pre-processor is still C code. Another example is https://doc.qt.io/qt-5/metaobjects.html

The con is that, well, it introduces a meta layer, and these meta layers are more often than not ad-hoc and ultimately became quite unwieldy. It's a design pattern that suggests that there is a feature missing from the language.

No absolutely not, I think that's the worst of both worlds. I mean something like `rails generate` where it's a parameterized block of generated code that you insert inline and then edit to your needs.

The disadvantage is that making sweeping changes is more work. The advantage is that making sweeping changes can be done incrementally. But the big win with code generators is that all you need to understand what's happening is right in front of you instead of having to mentally unwind a clunky abstraction.

Don't get me wrong if you have a good abstraction that reduces the use of mental registers do it! But you would and should do that regardless of boilerplate.

It's a design pattern that suggests that there is a feature missing from the language.

This is the part where I’ve been entertaining the idea of solving things at a language level (transpiler). It’s a dangerous idea because if we get better tools to extend the language and everyone does it, we’re all going to be fucked.

But I can’t shake the idea that some of our frameworks, if incorporated at a language level, could entirely eliminate the boilerplate.

I think this goes beyond one project. In your lifetime you just have to write certain things again and again and then you have to write the abstractions again and again.

Maybe that warrants a library, but then you also have to hook that up with the ever so slightly different boilerplate code.

If this 90% of the easy stuff is done for you, that gives you more time to focus on the 10% that matter.

I'd be willing to bet a reasonable amount that there's a large future for "subtractive software development" (maybe a slightly misleading or unfair term, since it'd include bugfixes).

Once we have multiple proven technologies that handle each of the functional areas that we collectively need, then we'll start to find greater benefit in maintenance, bugfixes, and performance improvements for those existing technologies and their dependencies than we find writing additional code and libraries.

> you and most likely the majority of programmers

You might be right (I haven't met the majority, I have no idea) about "the majority of programmers", but it seems a little rude to assume the person you are responding to is some talentless hack that can only import things off the internet they don't understand.

The point of APIs and libraries is abstraction: you can understand and use without the details.

(Now... you may argue that apis are often badly designed and implemented... but at least they are trying).

One problem with IDE's is that they can be antagonistic of good practices such as writing comprehensible code, small code bases, and good documentation.

I think as our field evolves, more work will be dealing with high level abstractions. There is a massive need for distributed systems design. Companies have big ambitions, but not enough labor to accomplish them.

There will still be plenty of low level systems programming work. The field is growing, not shrinking.

One impact this may have is that it may make tasks easier and more accessible, which could bring lots of new talent and could also apply downward force on wages. But the counter to that is that there is so much more work to be done.

I'm all for new tools.

Trying to figure out why in the world your comment was down voted.

You can only solve relatively small problems this way. As I get older, I like the physical act of programming less and less, and just want to solve problems so I can get going on all of my ideas backlog. I've been programming almost every day for the last 38 years. What I really want to do is solve (my) problems.

I really agree with this even though my experience is much smaller than yours.

The biggest place I think it is frustrating to write code is for ML pipelines where you know what you need, but it takes a few hours to wrangle files and pandas until you can run your idea/experiment.

Ermahgerd, yes! Doing this right now.

But programming is the greatest fun on earth. Wait no, being able to work on your ideas and communicating them to the computer is the greatest fun on earth. Now, if your only tools for communication are made by "productive developers", this is where the problem is. Not with programming itself.

I think that there's a division between "productive" developers and "meticulous" developers. I know that I'm not the first one. My best days are when I'm removing code. I'm very wary from using frameworks and huge libraries. I learned few frameworks and libraries, I've chosen few that correspond to my style and I'm very careful when it comes to adapting new ones. I prefer to spend a week coding auth layer rather than installing some SaaS connector and call it a day. I prefer to spend few days reading source code and developing my own solution (or just discarding the whole idea) rather than quickly google something and move on.

May be I'm just unprofessional, I don't know. I get my stuff done, may be not as fast, but at least I understand every bit of my code and I rarely have unexpected surprises. I understand that there are other approaches, but I just don't enjoy that way, so I follow mine as long as I can find work. And I actually like things that other people find boring, according to this thread. Withing "business code" - hate it, writing "auth layer" - love it.

I'm the same. I tend to get derailed on making my code philosophically "right" and aesthetically "soothing" (for lack of a better word), even when it doesn't obviously matter to the scope of the project, rather than just it to the point where it _works_ by some operation of the Holy Spirit. Unsuprisingly I'm the "is he working ?" guy (I may fit in the attention disorder category that was a point of discussion in the confidence thread[1] the other day). But at least I'm not the "his code broke our shit again" guy.

[1] https://news.ycombinator.com/item?id=27533988

I don't think you're unprofessional. In fact, your sentiment is a belief that was strongly held by early UNIX programmers. Two quotes I particularly like:

"The real hero of programming is the one who writes negative code." -- Douglas McIllroy

"One of my most productive days was throwing away 1000 lines of code." -- Ken Thompson

But unfortunately, we've come to a situation where SLOC and innovation for the sake of innovation is more important than code quality.

Sounds like you should be working on libraries instead of products then?!

> I think that there's a division between "productive" developers and "meticulous" developers.

There’s a huge difference between:

1. Writing the core logic for an algorithm from scratch

2. “Connecting things”: e.g. writing the “click” handler for a button press, adding an auth middleware to a HTTP request handler

The latter consists mostly of boilerplate code: code that thousands of developers have already written. Copilot is useless for the former, and great for the latter. It has no idea what algorithm you want to implement, since you may be the first to write it, but it has seen the code of countless other individuals who needed to write the same boilerplate.

> Almost as if programmers think that writing programs is the worst part of the job and ready to be automated away.

writing the programs is definitely boring garbage work. Typing is so slow and annoying - hence autocomplete being a standard tool. This is, to me, just fancy autocomplete.

> to an increase in boilerplate and the acceptance of it because they make it easier to manage.

Boilerplate optimizes for the right things - code that's easier to read and analyze, but takes longer to write. IDEs and tools like this cut the cost of writing, giving us easier to read code and easier to analyze code for free.

IDEs have supported templates forever. I never write out a full unit test, I type `tmod` and `tfn` and then fill in the blanks. This is basically the same thing to me.

> Folks that still expect you to only check in code you understand and can explain will become a minority.

This isn't true at all. Having used TabNine I don't have it write code for me, it just autocompletes code that's already in my head, give or take some symbol names maybe being different.

All this is is a fancy autocomplete with a really cool demo.

Boilerplate is only easier to read and analyze if you can be sure it is consistent, so you can tune it out. Usually though, there is this one getter method that is not quite like the others and you literally will not see the difference until it bites you.

We'll need more IDE enhancements, to highlight interesting pieces and desaturate standard boilerplate...

When I think of boilerplate I think of context that is made explicit. Things like type annotations, longer variable names, the lifetime or attributes of some class or data etc. These things are extremely helpful for a number of things - they convey context from writer to readers, they aid in proving the code correct, and they can make code faster.

The context almost always exists in the writers head. We all have a specification of our program based on our expectations, and we type out code to turn that model into an implementation. We only spend so much time conveying that model though - most of us don't write formal proofs, but many of us will write out type annotations or doc comments.

The cost is usually as simple as expressing and typing out the model in our head as code. Languages that are famous for boilerplate, like Java, enforce this - and it makes writing Java slower, but can also make Java code quite explicit (I'm sure someone will respond talking about confusing Java code, that's not the point).

Reducing the cost of conveying context from writer to reader means we can convey more of that context in more places. That's a huge win, in my opinion, because I've personally found that so much implicit context gets lost over time, but it can be hard to always take the time to convey it.

Think about how many programs you've read with single character variable names, or no type annotations, or no comments. The more of that we can fix, the better, imo.

Tools like this do that. TabNine autocompletes full method type signatures for me in rust, meaning that the cost of actually writing out the types is gone. That's one less cost to pay for having clearer, faster code.

>Boilerplate optimizes for the right things - code that's easier to read and analyze, but takes longer to write.

This is wrong and the same retarded logic Java used to defend not introducing var and similar features for ages. Boilerplate is usually noise around the actual logic - it's a result of limited abstractions. When you're repeating same code over and over you raise that segment to a separate concept, that's how abstraction and high level programming works - it increases readability and maintainability. Being easier to type has nothing to do with it.

Thanks for being the person who I knew would try to make this about Java. I don't care about Java, it was a trivial example.

The rest of your post doesn't really have to do with mine. Yeah, you can cut down on boilerplate with changes to languages... duh. But in terms of conveying context there's always a tradeoff of explicit vs implicit, and one of those costs is taking the time to actually turn your mental model into a written implementation - this eases that burden.

As I said, it's a fancy autocomplete.

>But in terms of conveying context there's always a tradeoff of explicit vs implicit

Exactly - if a tool let's you write it explicitly too easily you're making that the default, and it ignores the readability/maintainability side of the tradeoff.

Maybe it gets good enough to recognise when things can be factored out for better readability as well. But in my experience code generators rarely result in maintainable code.

> I wonder how long it will be until someone sets up the rest of the feedback loop and starts putting up github projects made of nothing but code from this tool, and it can start to feed on itself.

This is my actual hoped-for endgame for the ad based internet. At some point Twitter, FB, etc will be exclusively populated by bots that post ads, and bots that simulate engagement with those ads to drive up perceived value of advertising. They'll use AI to post comments that are really just ads or inflammatory keyword strings to drive further "engagement." The tech companies will rake in billions and billions of dollars in ad revenue, we'll tax all of it and use it to create flying cars, high speed rail, and an ad-free internet closed off to all non-humans. Occasionally a brave ML researcher may venture out into the "internet" to take field notes on the evolution of the adbot and spambot ecosystem.

I invite you to try automating this and let us know what happens. Try creating, let’s say 1000 accounts and try liking or posting and see what happens. I’ve seen that system at work and doubt you’d get very far.

More than that, you misunderstand how advertisers prioritise their money. They pay for outcomes. If they notice that over the past couple of months they’ve been receiving mostly bot traffic, they stop advertising. Not everyone all at once, but enough that revenue begins to decline. An ad based business that cares about the long term will do it’s best to weed out the inauthentic engagement.

> I invite you to try automating this and let us know what happens. Try creating, let’s say 1000 accounts and try liking or posting and see what happens. I’ve seen that system at work and doubt you’d get very far.

Yes, naive attempts at manipulation will be detected these days on big platforms. 5+ years ago such naive attempts were successful, though. A few years ago I made a proof of concept to show how easy it is to make new Reddit accounts and automate them, and had registered hundreds of accounts. Those logins still work even though Reddit has cracked down on naive automation attempts.

Today, that's why many firms buy real users' accounts. They'll hire people to manually login to the accounts and post. There's also the perpetual cat and mouse game between bot creators and platform owners, and the platform owners who benefit from the appearance of increased growth and engagement that's actually just bot activity.

> More than that, you misunderstand how advertisers prioritise their money. They pay for outcomes.

How they verify those outcomes, however, gets interesting. See, for example, College Humour going under due to inflated engagement metrics fed to them by Facebook video.

The most unlikely thing you mentioned is that we will be able to tax huge corporations.

You jest, but the parent is close to what I believe is a possible scenario - the one Nick Bostrom calls "a Disneyland with no children".

No tax, no flying cars, eventually not even humans around - just AI-driven companies endlessly trading with each other, in a fully-automated, self-contained, circular economy, from which sentient beings were optimized away.

The whole thing sounds a bit like Autofac (https://en.wikipedia.org/wiki/Autofac)

As a counterpoint to most of the other responses, I agree with this comment. In my eyes, this is very similar to the issue of bloated software being enabled by faster processors. This doesn't mean slower processors are the answer, but rather that there are often unintended consequences that need to be considered when solving for a problem. So, as an example of what could be better than making boilerplate easier to type, I would suggest programming languages, frameworks, and tooling that reduce the need in the first place would be worth considering.

Some people think the problem is that we don't have enough code. Anyone that has to maintain code knows that the problem is that we have too much code.

This is even better! Now we can generate code we might not even understand, without even hitting all the keys.

Not looking forward to dealing with this from a security point of view. It's difficult to get developers to accept responsibility for security vulnerabilities in libraries they've selected for their project ("That's not my code!"). I can see the same thing happening with generated code where they don't want to take responsibility for finding a way to remediate any vulnerabilities they didn't personally type in. Of course those who exploit the vulnerabilities won't care how it got into the code. They're just happy they're able to make use of it.

It says it's trained on "billions of lines of code"

I would augment that to "billions of lines of code that may or may not be safe and secure"

If they could tie in CodeQL into Copilot to ensure the training set only came from code with no known security concerns, that would be a big improvement.

This ignores the ladder of abstraction, which you apparetly need to be reminded of exists. Not all programmers need to work at the same level of abstraction: some programmers need to write original code all day long because their subject field is close to the metal and there are no premade solutions. For those folks, the idea of copy-pasting from SO is pretty ridiculous, although SO might have questions and answers that allow them to write their own code solutions based on the insights of others. Because we're not going to dismiss highly respected experts in our fields just because they helped answer good questions with good detailed answers on Stackoverflow, are we?

A few rungs up on the ladder we still have programmers but now the kind whose job it is to write as little code as possible, where their worth comes from knowing exactly how little code glue is needed to, necessarily and sufficiently, make other people's libraries work together to functionality that is larger than the sum of its parts. These folks aren't solving unique problems, they make things work with as little code as possible, and copy-pasting from SO for problems that have been solved countless times already by others is 100% fine: their expertise is in knowing how to judge other people's code to determine whether that's the code they need to copy-paste.

And then, of course, there all the folks in between those two levels of abstraction.

The biggest mistake would be to hear "programming" and think "only my job is real programming, all those other people are just giving me a bad name". Different horses and different courses, and different courses for different horses.

> As someone more aligned with the Dijkstra perspective, this seems to me like one of the single worst ideas I've ever seen in this domain.

Absolutely true.

If your code is so repetitive that can be correctly predicted by an AI, you are either using a language that lacks expressiveness or have poor abstraction.

The biggest problem in the software world is excessive complexity, excessive amounts of (poor) code and reinventing the wheel.

You're underestimating the sophistication of said AI.

All I can think of is how many times I've grabbed a code example from StackOverflow only to discover it had some obvious bug in it. The answer is many, many times.

If this results in more overall programmers or enabling existing programmers to make products quicker than before, it's a win!

Most codebases already majorly contain unread code; the libraries (node_modules, etc). I am sure we can figure out a pattern to separate human vs machine code in similar way.

If the code you are about to write is already written by someone else on the internet, that's probably not the most innovative part of your codebase anyway, so why waste time?

> If this results in more overall programmers or enabling existing programmers to make products quicker than before, it's a win!

I don't think I really agree with this sentiment. "More programmers" or "faster programmers" is meaningless (or even actively detrimental) if the quality of their output is lower. It's even worse if their output is plagued by subtle bugs, as AI systems are likely to produce.

The "quality programmers" (neckbeards) can continue their quality work. These new faster programmers can get other stuff done.

The one paying for these jobs can decide what level of quality they want, and hire/pay accordingly. How does that sound?

Cargo cults concerned me too but I realized that cargo-cult programming flourishes when it's enabled by a culture that doesn't care how the sausage is made. If the culture seeks full stack truth, it's not likely to get fooled by bad generated code, no matter whether it's generated by copy/paste, metaprogramming, or AI.

I'd love to know what Donald Knuth thinks given the history of literate programming.

I've used tabnine for a while, and it's mostly just been a faster executing normal autocomplete, with a %90 accuracy rate. It's a tradeoff. It didn't have the large snippet behavior in my usage like this new one although.

Somehow I don't see people discuss this kind of tools from the perspective of managing essential complexity versus accidental complexity. Maybe copilot just increases the abstraction level of coding, so we can treat generated code as a building block, just like we nowadays rarely needs to care about how to write assembly code or how a balanced tree works?

> Maybe copilot just increases the abstraction level of coding, so we can treat generated code as a building block

At this point it doesn't, and we can't, because Copilot is just a fancy autocomplete. The code is there, first class, in your file. It doesn't introduce new concepts for you, it just tries to guess what you mean by function signature + descriptive comments, and generates that code for you.

I think the mistake you might be making is assuming that any tool adopted is always used all the time. Even professional race car drivers probably opt for an automatic transmission over the manual on the mini-van if they get one. Different choices for different needs.

There will always be a place for meticulous consideration of exactly what's being done, and many levels of that as well. For the same reason people reach for python to mock up a proof of concept or throw something together that is non-essential but useful to have quickly, even meticulous programmers might use this to good effect for small things they don't care to spend a lot of time on because it's not as important as something else, or the language they're using for this small task isn't one they feel as proficient in.

The way I see it, the tool is only as good as the programmer using it. This tool will generate the individual code blocks for you, but you still have to understand how to put it all together to deliver a working app.

Sure there will be some codebases out there that are plastered together using this tool, but when it comes to delivering software that is well written, performant and maintainable over the course of several years, you're still going to need a lot of skilled engineers to pull that off.

Okay, and I'd argue that a good portion of programmatic wrangling is simply trying to do Y with Z. Something that's probably done 10,000 times over by others but in the silo'd confines of that single developer's workspace; an utter fucking mystery to them.

What's the carbon displacement for wasted time on those tasks? It might be brow raising.

In the (now not very) long run, programming was a job meant for computers, anyway. The future will look back at "programming" the way we now look at Charles Dickens characters toiling in soot-filled factories. It's not what people are best at, and it looks like soon there will be better ways to accomplish this job.

I don’t know if I agree with this, but I think it depends what you mean when you say “programming”.

I use programming as one of the examples of intrinsically human work.

You have a (general computing) machine that can do anything(), it only has meaning and utility from humans thinking about problems they have and how to solve them.

The hard part of programming is analysing what problems you have, and what you want to do about them.

This is why one of the distinguishing features between junior and senior programmers is that seniors tend to think about the (human) problem they’re solving a lot more.

Tools like copilot help with the physical interfacing between programmer and machine, but they don’t eliminate programming.

But a recurring worry people are expressing in this thread is: some people think they _do_, and how insidious that idea is.

The tool is great, the managers deciding that time spent thinking about its output, or developing their staff’s skills, is a waste because “just use what the AI says”, are the danger.

As long as people and computers exist, there will be programming.

not actually “anything”

> Someone will produce 5000 lines of code in a day for a new feature, but only read 2000 of those lines.

Shouldn't the one who has produced this code be responsible for making sure the integrity of it? 5k LOC in a day without test cases, then that is no code, it is a disaster.

I think the marketing here is about right. This is no AI programmer, but Copilot. It is an intelligent assistant that does some mundane things for you with probability of failing some of that even, but when the stars align, you are in luck.

I see this as INCREDIBLY useful for certain niche of programming:

1. Front end. Some components are really trivial but still requires some manual rewiring and stuff, this could be the life saver.

2. Templates for devops. Those are as soul crushing as possible, and I couldn't think of a better domain to apply Copilot to it.

Overall, this is a huge win for programmer productivity, with reasonable compromises.

Indeed, using tools to manage complexity tends to make the complexity acceptable and leads to more complexity.

If we exclude the VM the code is running on, and the OS layer, and the kernel, and the micro-code, and the standard lib, then people also like to include library code, and also like to depend on third party PaaS and SaaS aka the "cloud"... If you do know what all bits of your code does you can send me a PM. cough All software is shit, with few exceptions. Not necessary because the developers don't know their stuff, but likely because of business priorities, politics, and layers of management. Software is a "people problem". So if we remove the "people" we might get better software ;)

Your fears seem justified, as per the site itself:

Whether you’re working in a new language or framework, or just learning to code, GitHub Copilot can help you find your way. Tackle a bug, or learn how to use a new framework without spending most of your time spelunking through the docs or searching the web.

Thank you. If one trains an AI on a corpus of mediocrity, one should expect a mediocre result.

The first thing that comes to mind is the recent article on the front page about the docker footgun/default that allowed a hacker to wipe a website's database.

Coding is inherently difficult -- any tools even as basic as color highlighting/spell checking massively help understanding code in front of you. There isn't a hope this can replace any programmers but instead aid their workflow. I great example is simply refactoring code with SOLID after building a feature or fixing a bug -- a lot of this can be easily automated. Having a machine suggest and a human accept is a worthy trade off. Another similar example is the Google bot that presents search suggestions for you.

I don't think your concerns are well grounded.

Next step will be AI to approve the code, because. if someone is producing 5k LOC a day there are people who need to read & approve this code...

If we didn't need programmers to do the programming, that would be a perfect world.

This is inevitably leading to the moment where we don't need humans, but I'm fine with that.

People have made some variation of this argument since the move from writing binary to writing assembly.

With every new layer of abstraction there’s more power.

The long term benefit of a tool that can do this well far exceeds what humans can do by hand, but that may not be true in the very short term.

Either way, I suspect the benefits to be big.

I disagree with the comparison. This isn't abstraction, it is syntax completion. As if you typed the first four bytes and GitHub (mostly correctly it must be mentioned!) completed the remaining.

Unlike an additional abstraction layer, the readibility is not increased.

The end goal of this based on what I've seen from Open AI examples and related beta projects is more high level language -> code.

"Write a standard sign up page" -> Generated HTML

"Write a unit test to test for X" -> Unit Test.

It's more than just syntax completion - I'd argue that's the beginning of a new layer of abstraction similar to previous new abstraction layers. The demo on their main page is more than syntax completion - it writes a method to check for positive sentiment automatically using a web service based on standard english.

This is extremely powerful and it's still super early.

I saw one example that converted english phrases into bash commands, "Search all text files for the word X" -> the correct grep command.

That is a big deal for giving massive leverage to people writing software and using tools. We'll be able to learn way faster with that kind of AI assisted feedback loop.

Similarly to compilers, the end result can also be better than what humans can do eventually because the AI can optimize things humans can't easily, by training for performance. Often the optimal layout can be weird.

Not at all: this tool does not encourage more powerful abstractions, but the very opposite.

It makes boilerplate cheaper to churn out.

That entirely depends on the quality of the suggestion, does it not?

You sound afraid you'll be replaced by software.

Are you not?

Nah.

Cargo-cult programming has always been a problem, but now we're explicitly building tools for it.

I get what you're saying, but I'm not worried. At the end of the day, the programmer has to understand the code they're submitting, both the fine grain and the holistic context. If they don't know how to, or can't be bothered at least curate the suggestions the tool is making... then your organization has much bigger problems than can be helped by reading a Dijkstra paper or two.

Reply on news.ycombinator.com