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.
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.
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.
That's a dog whistle to find a better company/location.
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
Own code would be bad but libraries? That's kinda the idea of an abstraction layer.
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.
So many STLs are fucking unreadable. Golang's is the only one where I've actually enjoyed it a bit.
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.
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.
Check out the memoize example. That fails as soon as you pass anything non-primitive but there’s no one documenting that.
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.
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.
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.
It synthesizes new code based on a corpus of existing code.
It looks to me like they're suggesting you use Copilot to write the tests.
> 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.
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 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.
Perhaps AI should work on simplifying the existing stack first, without breaking the functionality. What about that?
I like abstractions as much as the next person, but oftentimes you can just make due with the exact thing.
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.
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.
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.
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.
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 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.
(Now... you may argue that apis are often badly designed and implemented... but at least they are trying).
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.
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.
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.
"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.
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.
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.
We'll need more IDE enhancements, to highlight interesting pieces and desaturate standard boilerplate...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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 one paying for these jobs can decide what level of quality they want, and hire/pay accordingly. How does that sound?
I'd love to know what Donald Knuth thinks given the history of literate programming.
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.
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.
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.
What's the carbon displacement for wasted time on those tasks? It might be brow raising.
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”
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.
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.
I don't think your concerns are well grounded.
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.
Unlike an additional abstraction layer, the readibility is not increased.
"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.
It makes boilerplate cheaper to churn out.
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.
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.