Not really. People are generally far faster at reading something and evaluating whether it's correct, than at writing something. In the same way it's faster to read a book than to write one.

Not to mention the time it takes typing, fixing typos, etc.

So this could genuinely be a huge timesaver if it helpful enough of the time.

I can _just_ read the code of course, and understand what it does - but just reading isn't analyzing it to the degree you do when you review/write the code. In that level of analysis you're looking for edge cases, bugs, etc. Reasons you'd write it differently. Which i suspect is functionally similar, if not identical, to writing it.

Honestly I don't even see how that's possible. Writing code, you're thinking about all the different ways to do it, eliminating the ones that won't work, evaluating the pros and cons of the ones that seem like they'll work, you start writing one and then realize it actually won't work, then start writing it a different way, try to decide what the best approach will be to make sure you're not committing an off-by-one error, and so on...

Whereas when you're reading code for correctness, you're just following the logic that's already there. If it works, it works. How could it possibly take longer than the whole creative process of coming up with it...?

Sure, maybe most people don't read code for correctness well. But then the code they write is surely even worse.

That's exactly the problem. If you "just follow the logic" you can miss important details or edge cases that you would be forced to deal with by coding it yourself.

I wouldn't mind using something like this for mundane tasks, but I would be very careful with these tools while developing high performance code intended to run on specific hardware.

If I'm reading code, I can give 100% of my attention to the logic and details and edge cases, so I'm more likely to pick them up.

While as I'm writing, I'm busy doing all of the stuff that writing code involves, so I'm more distracted and more likely to make mistakes.

This gets proved to me time and time again when I run something for the first time and have to debug it. I look at the offending line, and think -- how could I have made a mistake so obvious that it's immediately apparent? Well, because I was busy/distracted thinking of 20 different things while writing it. But it's immediately obvious when reading it, because it has my full attention now.

what? so people just write code and never read it back?

There was a simple function in java standard library which was wrong for years because of this phenomenon.

https://dev.to/matheusgomes062/a-bug-was-found-in-java-after...

"recursively list all the files in a directory C#"

https://stackoverflow.com/questions/929276/how-to-recursivel...

I imagine an AI copilot could streamline this, instead of searching, reading and verifying, copy pasting, and changing the variable names to my needs, I could now just type the method name, arguments, and documentation and it would similarly fill out the code for me. Then I have to check it (as I normally would).

Edit: In fact, people in this thread are finding exactly those problems in the example code, which you would assume had been checked fairly carefully.

I can imagine this being very useful in helping to type out what I consider to be „mechanical noise“: Things that you have to type out to satisfy an expression rather than to convey semantics.

A good example of how this type of noise manifests:

Observe two programmers, both being similarly strong in terms of many concepts except for mechanical expertise. One uses the editor as an extension of their body, it’s beautiful to watch, the other stumbles awkwardly over the code until it’s finished. You can observe the latter in programmers who are very smart and productive, but they either didn’t train their mechanics deliberately or maybe they lack that kind of baseline eye hand coordination.

Smart programmers are are not coding thousands of lines of code every day. There's so much more to in software engineering other than coding, that's why senior engineers spend less time writing code than juniors.

If a slow typer is using a auto-completer, he's not learning to type faster.

If auto complete fails, then the slow programmer will need to invalidate the code first, and then type it anyway.

All in all - maybe it's impressive AI research project, but I don't see it as a useful product.

The difficulty with high flexibility is that the expressions become very domain-specific very quickly, creating the challenge of learning the new abstractions. So one isn't just a LISP developer, one knows how to write in the specific forest of macros that have been built up around one specific problem domain. The end result is code that means nothing to a reader who doesn't have a dense forest of macro definitions in their brain (at least in this era, their IDE will likely helpfully pull up the macro definitions with a mouse-over or cursor-over gesture!).

Contrast with this approach, where the complexity of abstraction is being baked into the lower-flexibility language. The code is less dense, and that's a tradeoff... But grab any 10 developers off the street with experience in that language and have them read it and 8 of them will likely be able to tell you with some accuracy what the code is doing. Not a trick I've seen possible with even very experienced LISP developers on a codebase they've never seen before.

... and, of course, being able to grab a random 10 developers off the street and have 8 of them up-to-speed in no time at all is crack cocaine to big businesses with large and complex systems maintained by dozens, hundreds, or thousands of people.

Do you think there's a risk that a tool like this could lead to an explosion of the size of codebases written in these languages? It's great that programmers can be freed from the need to write boilerplate but I fear that burden will shift to the need to read it.

It is no different from a code review of another perhaps junior dev and only doing adding finishing touches.

There is plenty of boilerplate you have to write, Intellisense/ Auotfill only goes so far, this is next step in the evolution. Sure it is not perfect but if i can express my ideas faster, why not.

Also It is a very probably poor tool for new devs, they won't know that suggestion maybe not the best and probably won't ignore it when it is wrong as they won't know any better.

Code completion might be the new "junior dev."

While sure purist view is not wrong that average quality of outcome has dropped since 70s-80s, the quantum of throughput meant that impact has been positive and immense.

Similarly I am expecting this kind of tooling would open up to more types of new developers.

[1] all the mathematicans thought similarly perhaps during 50s and 60s.

And for those with experience, this will be obvious when reviewing their code. There's only two possibilities -- either copilot will get so good that it won't matter, or code written by copilot will have obvious tells and when someone is over-relying on it to cover up for a lack of knowledge, that will be very clear from repetition of the same sorts of mistakes.

That said, I can't wait to read the first postmortem where someone deployed code generated via Copilot that has a bug. I just hope it's not on a rocketship or missile guidance system.

Even something as simple as copying from the docs, it's usually a good place to signal deprecation, use-case applicability, API updates etc. you lose all that with the automation.

Oftentimes there's also discussion around a solution, and in many ways can swing one's decision on whether to use the code or not.