Hacker News Reader

> If you need to go through the suggested code to ensure it's correct, you may as well write it yourself?

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.

idk I always find writing code easier than reading code. Perl is a fantastic example of this.

I completely disagree with you. Reading code for correctness is difficult and not something most people do well at all. Reading code and reading for correctness are not the same, and most developers can write code a lot faster than they can verify it.

That’s what a REPL and automated tests are for.

Automated tests find all bugs and replace code review? I'd love some of those drugs!

No, of course not. I meant understanding what you write, while you write it. Also to add a bit of nuance: I typically spend much more time reading and thinking rather than writing. But I read REPL output, logs, test output just as much, sometimes more than the actual code.

I guess we just disagree?

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.

>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...?

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.

It's funny, I guess I'm just the opposite.

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.

Sometimes you don't quite know how to implement something, without thinking about it for a while. All of us would a lot of the time search StackOverflow for the solution to a simple problem, e.g.

"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).

I'd say it's more nuanced. Reading code properly _is_ writing code. Ie i have to work through the logic as if i'm writing it, which is effectively writing it in my head, before i know if that's what i believe to be optimal.

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.

It's pretty much this, but it's harder because if someone else wrote it, there's a level of indirection between how you would have written it and how they did which tends to need a bit of extra mental resolving/processing for correctness.

>most developers can write code a lot faster than they can verify it

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

Verifying code and reading it aren't the same thing. And yes, most developers don't verify their code as carefully as they should. But also, there are blind spots to verifying your own code because brains take shortcuts. At the same time, there are difficulties verifying other people's code because of different shortcuts brains take.

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...

I’m going to pile on the disagree train. My experience is that developers find (other people’s) code much harder to read. I suspect this tool will lead to code with subtle problems because people will skim it, shrug “eh, looks about right,” and move on.

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.

Honestly, this attitude (dismissing the feature even without trying it out) comes across as insecurity and gatekeeping.

Is “you’re gatekeeping!” the new “first comment!”? I fail to see the information gain from adding this message to every thread.

I honestly think this is solving a real problem with commonly used languages and their lack of syntax abstraction and expressiveness.

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.

It is even entirely possible that this approach hits a middle-ground that serves the corporate software-development space better than highly-flexible languages.

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.

I’ve seen macro heavy code that is very semantic and declarative. It’s a powerful tool, so it is natural that people need to learn and fail until they use it well.

Couldn't disagree more:

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.

Maybe I reacted optimistically because your objections are reasonable and relatable. But I‘m still very interested in how this will actually play out. I want to see and feel it in action.

I honestly think this is solving a real problem with commonly used languages and their lack of syntax abstraction and expressiveness.

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.

Damn that’s the best objection I read so far. Writing readable code is already hard and something I aspire to.

Think of it as a junior dev working under you and doing the grunt work of typing in your ideas. Sometimes he can StackOverflow a better snippet than you can write on your own, you will probably learn a bit from it, but it won't surprise you.

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.

Most people on HN will probably be fine for a while. This innovation though, once properly developed, could completely screw over anyone wanting to enter programming.

Code completion might be the new "junior dev."

All the computer scientists[1] at one point considered software developers and IT in the same light as higher level tooling evolved .

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.

> Potentially for newer developers it robs them of active experience of writing code.

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.

I imagine, for a while the complexity that Copilot can handle is limited to what most people would pull from stackexchange anyway. And if it helps autocomplete documentation and provide automatically generated (more descriptive) function/variable names, it will probably be a net positive for those limited use cases.

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.

As a hobbyist this is going to save me so much time. Little things like googling how to read CSVs in python for the 20th time add up and I think this should help solve that.

I'm not quite old enough to remember: when high level languages like C gained wide adoption, how much pushback was there from the philosophy that if you're not writing it in assembly, you're not really writing code?

All of the same can be said for copy-and-pasting code you find in a tutorial in Google search results or in a Stack Overflow answer. This just seems to be automating that process even further.

Those extra steps can be valuable, since you'll have to work to even find the right code to copy/paste, and the context which it's in can teach you something.

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.