4 ms·

The above is only true for GPT3.5 (and probably underestimates that as well). But completely false for GPT4. I had a bunch of deeply-nested map/flatmap code an

The above is only true for GPT3.5 (and probably underestimates that as well). But completely false for GPT4. I had a bunch of deeply-nested map/flatmap code and it rewrote it into a short pretty for-comprehension, error free. For those that haven't learned those desugaring rules cold, it's a massive help.

epicureanideal 3y ago
Isn't that the kind of thing an IDE could be able to do, just by programmatically swapping between the choice of syntax to express the same logic? Aren't there a relatively small, finite number of these cases that would cover a large percent of typical transformations, and do so with 100% reliability?
- FeepingCreature 3y ago
  Sure, given a buggy and brittle bundle of special cases. That sort of thing can work, I'd presume, if you use an IDE that's deeply integrated with your compiler and language development. With third-party tools, version skew alone makes it untenable, let alone that the amount of transformations you could want is basically unbounded. The cool thing about GPT is that it understands code contextually and flexibly. I can literally throw it syntax that was developed specifically for a single project, that it's almost certainly never seen before, and as long as it's similar to something it's seen elsewhere, GPT can figure it out. There's no way you're getting that from an IDE feature. I got GPT 3.5 to transform a (simple) function into return-early style a few days ago. It didn't quite get it right, but it got the correct idea. I did this by typing "Transform this code into return-early style." With an IDE feature, I'd have to hope the developers had heard of and cared about return-early style in the first place, and then that their tool was powerful enough to realize when and how to apply it. (Highly unlikely, IMO.) edit: In other words, > Aren't there a relatively small, finite number of these cases that would cover a large percent of typical transformations, and do so with 100% reliability? I believe the opposite is the case.
- tunesmith 3y ago
  Can an IDE answer followup questions of how those sugaring rules worked, and suggest other alternative formulations if I want part of it to be more explicit?

epicureanideal 3y ago

Isn't that the kind of thing an IDE could be able to do, just by programmatically swapping between the choice of syntax to express the same logic? Aren't there a relatively small, finite number of these cases that would cover a large percent of typical transformations, and do so with 100% reliability?

FeepingCreature 3y ago
Sure, given a buggy and brittle bundle of special cases. That sort of thing can work, I'd presume, if you use an IDE that's deeply integrated with your compiler and language development. With third-party tools, version skew alone makes it untenable, let alone that the amount of transformations you could want is basically unbounded. The cool thing about GPT is that it understands code contextually and flexibly. I can literally throw it syntax that was developed specifically for a single project, that it's almost certainly never seen before, and as long as it's similar to something it's seen elsewhere, GPT can figure it out. There's no way you're getting that from an IDE feature. I got GPT 3.5 to transform a (simple) function into return-early style a few days ago. It didn't quite get it right, but it got the correct idea. I did this by typing "Transform this code into return-early style." With an IDE feature, I'd have to hope the developers had heard of and cared about return-early style in the first place, and then that their tool was powerful enough to realize when and how to apply it. (Highly unlikely, IMO.) edit: In other words, > Aren't there a relatively small, finite number of these cases that would cover a large percent of typical transformations, and do so with 100% reliability? I believe the opposite is the case.
tunesmith 3y ago
Can an IDE answer followup questions of how those sugaring rules worked, and suggest other alternative formulations if I want part of it to be more explicit?