I think an interesting distinction is this: it's not that 90% of the typing you do is necessarily useless, it's that it's been done before. Copilot is, in a sense, drawing from a corpus of prior work. In that way you are kind of using it as if you found a published library for your more specific use cases. So it's allowing you to draw on prior work without necessarily having external packages split up with the granularity of many variations of functions (which, ideally, would allow you to pull in exactly what you need from prior work, but would certainly be onerous in practice).

That being said, I've never used Copilot myself, so I can't speak very confidently about it. But from what I've seen, it kind of allows you to incorporate every library that's ever been made open source into your project, but in a more granular fashion. Which naturally would save you some typing :)

P.S. I realize Copilot isn't necessarily copying other code verbatim, though I assume pretty often it basically ends up doing that, at least in pieces.

This is an interesting take. One does need to draw a distinction between “what everybody writes” (copilot generates) and “what has to be written” (this code is the ‘useless’ stuff bemoaned by the parent comment). Obviously everybody writes what has to be written, but you're right that there is a distinction.

One gets a vision of the copilot autocomplete, as kind of missing what would be an essential highlight, in the templates it provides. “These parts highlighted in red, do not change those, for some reason everybody does it that way. But these parts highlighted in yellow, I've seen a bunch of different takes on those; this is where some variation occurs and where you might want to customize it yourself.”

On this take, copilot is a poor way of providing syntactic templates—macros—and indeed those macros take the form of template substitution, which means they form in theory a lambda calculus for that metalanguage.

That is itself interesting because I only know of one programming language which says “we are going to live out here in la-la-functional-programming-math-land, but we are going to describe values which are actual fragments of computer programs,” and that language is Haskell—though never used to write at this scale!. Interesting to think that the Ur-goal of Copilot is to provide what you were missing because you didn't wrap your language in Haskell in the first place!

With that said, a better way to start with metalanguage design if this problem irks you is probably not Haskell itself (it doesn't have an easy way to swap out its compile target language from C-- to some other target, I don't think) but something like Ometa2: http://wiki.squeak.org/squeak/3930

I feel like some languages make it much easier (or at least require less code) to accomplish certain tasks (Perl, for text processing, and Erlang for concurrency/distributed systems), while other languages make it more practical to do anything at all, but the tradeoff is that they’re much more verbose.

Kitchen sink languages require you to build the kitchen before you can cook.

Very interesting. I don't have experience with copilot, but with my own programming I tend to abstract heavily until repetition is removed and there's little to repeat (that said there are places where the language, C# in my case, could support my style of programming better). I'll check out some vids.

An interesting point. I wonder if the knowledge contained in github copilot could somehow be extracted to come up with suitable semantic abstractions.

a programming language (together with its standard library) should guide you toward safe code, while keeping an enjoyable experience.

Saying "this thing is hard to get right, so the PL should make you feel the pain" is only marginally better than a language that pretends the problem isn't there at all.