[sktrdie]

I think you’re missing what the problem they’re trying to solve is. They’re solving the problem of “writing code faster”

With that in mind I think this problem is totally real and worth solving. If copilot can save me those mundane moments during my day where I have to figure out “how to do this common thing that I already did 100 times” then it’s a win for everyone.

It’s not trying to solve the whole of programming. It’s just a nice tool to let you actually concentrate on the non-automated parts of coding such as: actually translating requirements into code.

[jameshart]

Well there’s your problem.

We don’t need more code. In general, code is a liability. A tool that helps create more configurations of the same terrible boilerplate incantations that we already have to maintain in a million code based is just adding to the problem.

[UncleMeat]

We've had sixty years of serious software development and the community still doesn't have a strong idea of how to actually write applications in the manner you describe and then evolve those applications according to new requirements. Every decade we get tons and tons of new best practices and the fact is that virtually all applications, even those written by world experts, end up as a mess.

"Just write code beautifully" is a great problem to try to solve, but we shouldn't let that problem prevent us from making minor local optimizations in engineering practice.

[alkonaut]

Yes. And this is the problem we have.

Of course lots of boilerplate should indicate we need new libraries or better frameworks. But we don’t.

We’re stuck writing things that often needs 50 lines of boilerplate.

This is the wrong solution but that doesn’t mean it’s bad. Someone (too many..) is surely writing new frameworks and better libraries. But meanwhile thousands if people really do have to add boilerplate to million line codebases.

[wahnfrieden]

You don’t think they will add dependency suggestions later? Seems within the vision

[zabzonk]

> how to do this common thing that I already did 100 times

You don't do it 100 times - you do it once, test it thoroughly, and put it in a library.

[medstrom]

Easy to say. Of course you do that when you can. What afflicts me is all the cases when the task is subtly different, with different requirements, but still feels like something I've done before.

[indigochill]

At the code level, that's parameters in a library function. At the infrastructure level, currently my team is using Terraform templates. I feel like we will probably restructure that "soon" to be more about composing infrastructure out of common blocks rather than inheriting from an entire template, but either way, this does seem to be a solvable problem at the infrastructure layer as well.

As you imply, it is significantly easier to say than to do effectively, but I've yet to see any situation where it -can't- be done (but I'm curious what one looks like if someone's run into this).

[cortesoft]

> At the code level, that's parameters in a library function

Sure, so you keep adding more parameters to the library function and then pretty soon you can’t remember all the parameters so you have to look them up every time you want to invoke it from your code… which is exactly the perfect use case for AI like this to help you remember the correct parameters to call.

[JetSpiegel]

It's turtles all the way down. Write another library with the original library as a dependency.

[ipaddr]

AI can make you write horrible code if you ask it to. Don't keep adding parameters endlessly and use the AI to somehow make sense of it.

But what you want is: Dependary injection.

[medstrom]

Keeping in mind I'm a hobbyist, not a professional, but it seems to me much of coding boils down to this process of refactoring, spinning out libraries and restructuring to use Terraform or whatever, and at some point the process itself is what's repetitive.

[twodave]

Not OP but I think the gist was more about solving the same/similar class of problem in a different context. You’re not going to build a library to abstract away certain things, for lots of good reasons. E.g. in OOP you may intentionally not use inheritance between a few similar (but distinct) business cases because of the overall maintenance burden/rigidness it would introduce. So you end up with more boilerplate, but your codebase is overall more flexible.

[elcomet]

When you use libraries or frameworks, you often write the same or very similar lines.

[blunte]

That to me is an indication of a need for an even higher level abstraction.

At this point we should be able to go through a questionnaire, and software (not an AI, but definitely algorithm with rich knowledge and rules) would generate a quality starting system.

$ I need an app

Q1. do you need it to be available on the web?

A1. yes

Q2. do you need users with accounts?

A2. yes

Q3. do you want local passwords, and/or third party connections such as Github, Google, Facebook, etc.? A3. local and third party

...

Qm. Do you have a programming language preference? [Ruby, Java, Python, ...]

Am. Ruby

Qn. Do you have a database preference? [MySQL, PostgreSQL, ...]

An. PostgreSQL

...

Add some theme options and other goodies, and you essentially have an app starter kit. Granted, you still have to know the technologies and plumbing since inevitably you'll need to change something that was preconfigured, but this would save a lot of time (and result in more consistent foundations across apps.

Ultimately I hope this goes even higher level to no-code or nearly no-code solutions. It might mean fewer choices, but that can also be a good thing. I imagine a majority of all software needs can be met with just a few predefined configurations. Then you can decide if you want to change your needs to fit the easy solutions, or if it's really worth going custom.

[ptx]

Such starter kits exist, e.g. JHipster[1]. The problem is that after you've generated the starter code, this big heap of code (that you're not familiar with the details of) is now yours to maintain and upgrade.

[1] https://www.jhipster.tech/

[blunte]

Indeed. So the last mile is how to reconfigure after the fact. This has been a problem for a long time with builders.

Perhaps one solution is to compartmentalize additional changes and configurations so they can be managed a bit easier while the foundation is updated.

It’s not an easy problem to solve, but I think we might be better off if the great minds worked on this problem instead of the low level code AI.

[iib]

There is also cookiecutter [1], that attempts a crack at the same problem you are describing. There is also a nice website [2] that searches for all the cookiecutter templates and lists them.

[1] https://cookiecutter.readthedocs.io/en/1.7.2/ [2] http://cookiecutter-templates.sebastianruml.name/

[elcomet]

I don't agree about the level of abstraction.

It is often recommend to not write a function if you call it only once or twice. So most functions will be called multiple times in your code.

Copilot can be useful here as it will autocomplete all arguments, based on the context (existing variables) and knowledge about the functions arguments, or previous usages. Of course sometimes it is wrong, but this is still very useful to me !

[donmcronald]

If you've done something 100 times, wouldn't it be faster to copy / paste the implementation you wrote (and know is good) than to rely on something like copilot and have to review / check the solution every single time?

I think what's actually going to happen is that copilot will be successful, but will be a much worse version of poor quality outsourcing. There are going to be people "writing code" that don't even have the ability to evaluate the implementation.

You see the same thing in some industries where the institutional knowledge of the baby boomers is disappearing. No one stays at the same job for more than a few years and you can see people making mistakes with things that are out by a factor of 10x or 100x sometimes. Very often people don't have the ability to grasp the basic concepts of the work they're doing. I think the same thing will bleed over to software development a lot over the next decade.

I also have a huge objection to having any code I write used to develop an "AI" for the benefit of a huge corporation. Do I get a cut? I doubt it. That alone should be enough for people to quit using GitHub. They're training they're own replacement and are too dumb to see it IMO.

[jfengel]

The problem is that you need to find it. There are thousands of things you've done those hundreds of times, scattered throughout all the code you've ever written. Going to find it can take as long as deriving the information from scratch -- again.

I often end up solving it by repeating my Google, and frequently the StackOverflow page will still be marked as having been read.

[citrin_ru]

If it is not something temporary a line of code is written once and then read many time by many people (for different reasons). Over the long run speed of reading more important than speed of writing. If copilot doesn’t help to write easy to read code it would make the problem worse.