Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2021-07-03

Channels

#off-topic
<
2021-07-03
>
dgb2311:07:02

A list of random thoughts: There has been much discussion about GitHub Copilot. Assessments are ranging from “Hey this is useful for boilerplate code” to “A senior programmer doesn’t want this, also GPL”. I think there is something here that is worth exploring or learning about. I think Copilot might be the wrong approach, or rather too fuzzy and hand-wavy, but I think there is a real issue that is surfacing in these discussions: What we as programmers actually want to do is communicate intent, and this might or might not be accommodated by language facilities and abstractions of our platforms. For one, I think if we need tools to write boilerplate for us, based on previously written code, then we are just not using the right tool for the job, except if the intent is to actually write boilerplate so we can see the right abstractions emerging. In expressive, dynamic languages like Clojure we have the tools to semantically compress code - avoiding boilperlate. The actual problem is not writing code, but reading and understanding it. A REPL, first class data and functions, immutable data structures, metadata and so on can help us with that. Which is fantastic! But we’re still doing a kind of low level expression based reasoning by understanding smaller things and composing smaller things to larger ones. This bottom up, expression based reasoning is paramount to really understand a given program (or parts of it). But we have nothing to guide us through. This is maybe where some form of AI could help? It doesn’t need to be the kind of ML AI that is discussed above. What comes to mind first is spec and instrumentation. We have a way of saying “This piece of lego doesn’t fit on that piece of lego, because of this assertion.” - where the pieces are not just basic types, but very expressive shapes that declare assumptions and guarantees. What we cannot say is “Which assumptions are likely to be wrong?” and “What might be a piece that is missing between these lego tiles to satisfy these guarantees?“. Say I go from A -> B -> D, there is a tool that says: Try putting in C between B and D.

borkdude11:07:21

I've considered something like that for https://borkdude.github.io/re-find.web/

nice 2
borkdude11:07:39

But I didn't consider that worth the investment yet

dgb2311:07:07

I should have mentioned re-find.web and also clj-kondo because they popped into my head when writing this!

dgb2311:07:09

One thing that would push it into the direction above would be a notion of composition, so it actually finds something when I say [1 2] -> [2 3]

borkdude11:07:54

right, it should find map inc right, but I think no matter how intelligent this thing can be made, the user should get some education first to he/she can ask better questions, since you basically want to ask the question: give me the function f for 1 -> 2

dgb2315:07:18

In the trivial case I agree! But it means you already know map. What if the function is provided from a lib you are not yet comfortable with? Or a composition thereof. Or what if you want to undrrstand something from the outside (debugging) rather from within its components?

borkdude15:07:35

yep, those are interesting cases, but considering the amount of traffic/questions I get from re-find.web I didn't think such a tool would be very much used. once you get the basics of Clojure you tend to not need such a tool anymore I think

sova-soars-the-sora17:07:14

Did you see Co-Pilot auto complete the Quake source code including magic floating point number 0xBwhatever by John Carmack?

nate sire17:07:28

I saw CoPilot... but not sure if it can program an entire code base for you?

dgb2317:07:16

Yes. It was pretty much an exact copy right?

dgb2317:07:42

@U04V15CAJ you might be right! Maybe there is a subset functionality that is useful for understanding and debugging though.

nate sire17:07:28

is it on youtube? CoPilot actually reverse engineered Quake? Or you mean it just helped assist someone in cloning the code?

nate sire17:07:15

I thought CoPilot was just to assist in writing boilerplate? Not actually reverse engineer a program?

emccue17:07:42

kinda curious about how well it would do with clojure

emccue17:07:57

my guess is not well at all given the low amount of code to train on

Juλian (he/him)18:07:02

Copilot seems to also auto complete secrets like API-Keys

mpenet18:07:42

It's gpl code (qrsqrt), great way to get into licensing issues

nate sire18:07:39

I just tried to install CoPilot but there is a wait list

ozzymcduff17:07:58

Is it just me or does copilot imply that there is too much boilerplate in many mainstream languages/frameworks?

☝️ 10
2
phronmophobic23:07:16

I don't think copilot necessarily implies that the target languages/frameworks have too much boilerplate. It certainly helps with spitting out boiler plate, but it's really common to have some starter code for specific tasks (eg. requiring the right namespaces and making a place to fill in data/functionality). In many cases, I wouldn't consider that "too much" boilerplate. Basically, anything that you would copy and paste from a Readme would be convenient as an auto suggestion from your IDE. IMO, Just about every clojure library has something like that.

🙌 3
👍 2
nate sire14:07:49

@U3JH98J4R A lot of Clojure code is compact, custom, DSL... I think Clojure would be one of the least affected languages. I see CoPilot applying more to boilerplate in frameworks and a language like Go.

andy.fingerhut12:07:00

I got a bit of a chuckle coming across a link to this StackOverflow question asking about "round brackets": https://stackoverflow.com/questions/68220522/what-do-round-brackets-mean-in-the-output-of-clojure-test-failures I've heard of square brackets and curly braces, but not those 🙂

javahippie13:07:07

To be honest, the whole bracket/parenthesis/braces is quite confusing to non-native speakers. In Germany everything is a „Klammer“ 😄

borkdude13:07:01

in Dutch "haakje"

borkdude13:07:48

haakjes = () accolades = {} vierkante haakjes = []

🙂 2
💪 2
dpsutton13:07:20

I could get onboard with switch to klammer. That is a fantastic word

👍 6
borkdude13:07:28

ok, let's do it

Thomas Moerman14:07:11

Klammer, that's a great name for an industrial synthwave band.

💡 2
seancorfield16:07:11

I know a lot of non-programmers who refer to all of (, [, { as "brackets", and so they will sometimes qualify with "round", "square", "curly". I think it's really only programmers and maybe English majors who say "parens"/"parentheses", ("square") "brackets", and "braces"? I can see how someone unfamiliar with English and/or programming would find this pretty confusing...

👍 2
teodorlu14:07:47

Would Github copilot be a thing if people used a concise language in the first place?

2
☝️ 6
sova-soars-the-sora17:07:54

with enough source code to train an autocomplete dataset based on comments, yes

vemv15:07:02

or if each PL community self-organised in high-quality, discoverable libraries (we're kinda there... some communities more than others. IMO we're the best one in that aspect, except for some Lisp Curse in terms of effort duplication)

👍 4
sova-soars-the-sora17:07:14
replied to a thread:A list of random thoughts: There has been much discussion about GitHub Copilot. Assessments are ranging from “Hey this is useful for boilerplate code” to “A senior programmer doesn’t want this, also GPL”. I think there is something here that is worth exploring or learning about. I think Copilot might be the wrong approach, or rather too fuzzy and hand-wavy, but I think there is a real issue that is surfacing in these discussions: What we as programmers actually want to do is communicate _*intent*_, and this might or might not be accommodated by language facilities and abstractions of our platforms. For one, I think if we need tools to write boilerplate for us, based on previously written code, then we are just not using the right tool for the job, _*except if the intent is to actually write boilerplate so we can see the right abstractions emerging*_. In expressive, dynamic languages like Clojure we have the tools to semantically compress code - avoiding boilperlate. The actual problem is not _*writing*_ code, but _*reading and understanding*_ it. A REPL, first class data and functions, immutable data structures, metadata and so on can help us with that. Which is fantastic! But we’re still doing a kind of low level expression based reasoning by understanding smaller things and composing smaller things to larger ones. This bottom up, expression based reasoning is paramount to really understand a given program (or parts of it). But we have nothing to _*guide*_ us through. This is maybe where some form of AI could help? It doesn’t need to be the kind of ML AI that is discussed above. What comes to mind first is spec and instrumentation. We have a way of saying “This piece of lego doesn’t fit on that piece of lego, because of this assertion.” - where the pieces are not just basic types, but very expressive shapes that declare assumptions and guarantees. What we cannot say is “Which assumptions are likely to be wrong?” and “What might be a piece that is missing between these lego tiles to satisfy these guarantees?“. Say I go from A -> B -> D, there is a tool that says: Try putting in C between B and D.

Did you see Co-Pilot auto complete the Quake source code including magic floating point number 0xBwhatever by John Carmack?

sova-soars-the-sora18:07:56
replied to a thread:A list of random thoughts: There has been much discussion about GitHub Copilot. Assessments are ranging from “Hey this is useful for boilerplate code” to “A senior programmer doesn’t want this, also GPL”. I think there is something here that is worth exploring or learning about. I think Copilot might be the wrong approach, or rather too fuzzy and hand-wavy, but I think there is a real issue that is surfacing in these discussions: What we as programmers actually want to do is communicate _*intent*_, and this might or might not be accommodated by language facilities and abstractions of our platforms. For one, I think if we need tools to write boilerplate for us, based on previously written code, then we are just not using the right tool for the job, _*except if the intent is to actually write boilerplate so we can see the right abstractions emerging*_. In expressive, dynamic languages like Clojure we have the tools to semantically compress code - avoiding boilperlate. The actual problem is not _*writing*_ code, but _*reading and understanding*_ it. A REPL, first class data and functions, immutable data structures, metadata and so on can help us with that. Which is fantastic! But we’re still doing a kind of low level expression based reasoning by understanding smaller things and composing smaller things to larger ones. This bottom up, expression based reasoning is paramount to really understand a given program (or parts of it). But we have nothing to _*guide*_ us through. This is maybe where some form of AI could help? It doesn’t need to be the kind of ML AI that is discussed above. What comes to mind first is spec and instrumentation. We have a way of saying “This piece of lego doesn’t fit on that piece of lego, because of this assertion.” - where the pieces are not just basic types, but very expressive shapes that declare assumptions and guarantees. What we cannot say is “Which assumptions are likely to be wrong?” and “What might be a piece that is missing between these lego tiles to satisfy these guarantees?“. Say I go from A -> B -> D, there is a tool that says: Try putting in C between B and D.

video of the autocomplete ^.^ https://twitter.com/mitsuhiko/status/1410886329924194309

ozzymcduff17:07:58
replied to a thread:A list of random thoughts: There has been much discussion about GitHub Copilot. Assessments are ranging from “Hey this is useful for boilerplate code” to “A senior programmer doesn’t want this, also GPL”. I think there is something here that is worth exploring or learning about. I think Copilot might be the wrong approach, or rather too fuzzy and hand-wavy, but I think there is a real issue that is surfacing in these discussions: What we as programmers actually want to do is communicate _*intent*_, and this might or might not be accommodated by language facilities and abstractions of our platforms. For one, I think if we need tools to write boilerplate for us, based on previously written code, then we are just not using the right tool for the job, _*except if the intent is to actually write boilerplate so we can see the right abstractions emerging*_. In expressive, dynamic languages like Clojure we have the tools to semantically compress code - avoiding boilperlate. The actual problem is not _*writing*_ code, but _*reading and understanding*_ it. A REPL, first class data and functions, immutable data structures, metadata and so on can help us with that. Which is fantastic! But we’re still doing a kind of low level expression based reasoning by understanding smaller things and composing smaller things to larger ones. This bottom up, expression based reasoning is paramount to really understand a given program (or parts of it). But we have nothing to _*guide*_ us through. This is maybe where some form of AI could help? It doesn’t need to be the kind of ML AI that is discussed above. What comes to mind first is spec and instrumentation. We have a way of saying “This piece of lego doesn’t fit on that piece of lego, because of this assertion.” - where the pieces are not just basic types, but very expressive shapes that declare assumptions and guarantees. What we cannot say is “Which assumptions are likely to be wrong?” and “What might be a piece that is missing between these lego tiles to satisfy these guarantees?“. Say I go from A -> B -> D, there is a tool that says: Try putting in C between B and D.

Is it just me or does copilot imply that there is too much boilerplate in many mainstream languages/frameworks?

☝️ 10
2