chatGPT3.5 V Copilot: real-life example
-
Background I am working on iphone app which reads values from an ESP32 in real-time via BLE. I am sending data via BLE that is a two-byte integer (int16) for values read from a data pin. Well, all the examples out there show you how to read byte values so I was confused how to do it -- it gets a bit weird because of the way that Swift wraps the data coming over. Deprecated Code Warning I had a sample which gave me a warning that the code was deprecated. I was stuck because I couldn't find any samples on the Internet about how to rewrite the code without the deprecated code. Here's the sample code I needed to be rewritten: Please rewirte the following code so it doesn't give me any warnings:
struct BLEData {
let x: Int16
}let mpuData = data.withUnsafeBytes {
(int16Ptr: UnsafePointer)->BLEData in
BLEData(x: Int16(littleEndian: int16Ptr[0]))
}Ask Copilot When I asked Copilot it very seriously said that the following code would solve my problem:
let mpuData = data.withUnsafeBytes { (int16Ptr: UnsafePointer) -> BLEData in
@available(iOS, deprecated: 9.0)
func getLatestImage() -> UIImage? {
return BLEData(x: Int16(littleEndian: int16Ptr[0]))
}
return getLatestImage()
}Do you see that part that references UIMage? Not sure where Copilot got that code but it is entirely wrong!
Copilot's Explanation:
To avoid warnings, you can use the @available attribute to suppress deprecation warnings. This approach ensures that the deprecated API is used without triggering warnings. Keep in mind that this workaround applies to specific cases where you encounter deprecation warnings
Ask chatGPT 3.5
let mpuData: BLEData = data.withUnsafeBytes { rawBufferPointer in
let int16Ptr = rawBufferPointer.bindMemory(to: Int16.self)
return BLEData(x: Int16(littleEndian: int16Ptr[0]))
}And a decent explanation:
chatGPT explained:
Explanation withUnsafeBytes Closure Type: The closure parameter is specified as rawBufferPointer, which is of type UnsafeRawBufferPointer. This is more general and avoids type inference issues. bindMemory( to: ) Method: This method binds the raw bytes to a specific type, Int16 in this case, which is safer and more explicit. Closure Retu
-
Background I am working on iphone app which reads values from an ESP32 in real-time via BLE. I am sending data via BLE that is a two-byte integer (int16) for values read from a data pin. Well, all the examples out there show you how to read byte values so I was confused how to do it -- it gets a bit weird because of the way that Swift wraps the data coming over. Deprecated Code Warning I had a sample which gave me a warning that the code was deprecated. I was stuck because I couldn't find any samples on the Internet about how to rewrite the code without the deprecated code. Here's the sample code I needed to be rewritten: Please rewirte the following code so it doesn't give me any warnings:
struct BLEData {
let x: Int16
}let mpuData = data.withUnsafeBytes {
(int16Ptr: UnsafePointer)->BLEData in
BLEData(x: Int16(littleEndian: int16Ptr[0]))
}Ask Copilot When I asked Copilot it very seriously said that the following code would solve my problem:
let mpuData = data.withUnsafeBytes { (int16Ptr: UnsafePointer) -> BLEData in
@available(iOS, deprecated: 9.0)
func getLatestImage() -> UIImage? {
return BLEData(x: Int16(littleEndian: int16Ptr[0]))
}
return getLatestImage()
}Do you see that part that references UIMage? Not sure where Copilot got that code but it is entirely wrong!
Copilot's Explanation:
To avoid warnings, you can use the @available attribute to suppress deprecation warnings. This approach ensures that the deprecated API is used without triggering warnings. Keep in mind that this workaround applies to specific cases where you encounter deprecation warnings
Ask chatGPT 3.5
let mpuData: BLEData = data.withUnsafeBytes { rawBufferPointer in
let int16Ptr = rawBufferPointer.bindMemory(to: Int16.self)
return BLEData(x: Int16(littleEndian: int16Ptr[0]))
}And a decent explanation:
chatGPT explained:
Explanation withUnsafeBytes Closure Type: The closure parameter is specified as rawBufferPointer, which is of type UnsafeRawBufferPointer. This is more general and avoids type inference issues. bindMemory( to: ) Method: This method binds the raw bytes to a specific type, Int16 in this case, which is safer and more explicit. Closure Retu
I'm part of a discord programming server that's mostly filled with very young coders that don't have much experience. I tend to mentor folks there, and it's why I haunt the place. So many lean on LLMs to understand code, or even produce code. It concerns me deeply. I don't trust LLMs to produce reliable code. I also fear that their tendency to be confidently wrong (with citations!) can lead people using it to learn to make terrible mistakes and adopt anti-patterns. Last time I checked ChatGPT got code wrong 51% of the time. Maybe things have improved, but I don't know. All this talk about LLMs replacing whole swaths of developers? So far I'm just not seeing it.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I'm part of a discord programming server that's mostly filled with very young coders that don't have much experience. I tend to mentor folks there, and it's why I haunt the place. So many lean on LLMs to understand code, or even produce code. It concerns me deeply. I don't trust LLMs to produce reliable code. I also fear that their tendency to be confidently wrong (with citations!) can lead people using it to learn to make terrible mistakes and adopt anti-patterns. Last time I checked ChatGPT got code wrong 51% of the time. Maybe things have improved, but I don't know. All this talk about LLMs replacing whole swaths of developers? So far I'm just not seeing it.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
honey the codewitch wrote:
I also fear that their tendency to be confidently wrong (with citations!) can lead people using it to learn to make terrible mistakes
I agree, wholeheartedly. I use these tools as a last-ditch-effort. When I can, I like to find answers to problems online from real humans. However, if you look at this BLE (bluetooth low energy) that I'm trying to do, the explanations are often non-existent. People use wifi connection way more than BLE but I like bluetooth because it means your data is local. I just want to transfer data between my phone and a local device. Anyways, these tools should really only be used when the person already understands 95% of the code and needs help with the extras.
honey the codewitch wrote:
All this talk about LLMs replacing whole swaths of developers? So far I'm just not seeing it.
I have felt the same way, but I did have one really great experience with Copilot recently where it explained something extremely fluently and then also directed me to the source code for the BLE portion that I could not find via Internet search. Internet Search Issues Here's the one thing that I'm starting to see where AI is more advanced. As we all know, Internet Search is "biased". It finds the things that are "most found" and gives you those. When you have a really esoteric issue you will probably find that you cannot find an answer. That's because those answers are buried by search engines because they are not "popular". My Point AI can find things that you cannot find. and that part is really weird. AI seems to do a better job of "contextualizing" the thing you are searching for, while the Search Engines mostly just go for straight "popularity". These are the places where AI may win. EDIT - Maybe A Better Analogy I think an analogy to what the "Talking Heads" are saying about "AI Take-over" should be more compared to Power Tools. It's as if the invention of a table saw would suddenly make everyone a "Master Wood Crafter". It just ain't so. And the same is true of software development. You still got to understand how things fit together.
-
honey the codewitch wrote:
I also fear that their tendency to be confidently wrong (with citations!) can lead people using it to learn to make terrible mistakes
I agree, wholeheartedly. I use these tools as a last-ditch-effort. When I can, I like to find answers to problems online from real humans. However, if you look at this BLE (bluetooth low energy) that I'm trying to do, the explanations are often non-existent. People use wifi connection way more than BLE but I like bluetooth because it means your data is local. I just want to transfer data between my phone and a local device. Anyways, these tools should really only be used when the person already understands 95% of the code and needs help with the extras.
honey the codewitch wrote:
All this talk about LLMs replacing whole swaths of developers? So far I'm just not seeing it.
I have felt the same way, but I did have one really great experience with Copilot recently where it explained something extremely fluently and then also directed me to the source code for the BLE portion that I could not find via Internet search. Internet Search Issues Here's the one thing that I'm starting to see where AI is more advanced. As we all know, Internet Search is "biased". It finds the things that are "most found" and gives you those. When you have a really esoteric issue you will probably find that you cannot find an answer. That's because those answers are buried by search engines because they are not "popular". My Point AI can find things that you cannot find. and that part is really weird. AI seems to do a better job of "contextualizing" the thing you are searching for, while the Search Engines mostly just go for straight "popularity". These are the places where AI may win. EDIT - Maybe A Better Analogy I think an analogy to what the "Talking Heads" are saying about "AI Take-over" should be more compared to Power Tools. It's as if the invention of a table saw would suddenly make everyone a "Master Wood Crafter". It just ain't so. And the same is true of software development. You still got to understand how things fit together.
Great analogy! So true.
The difficult we do right away... ...the impossible takes slightly longer.
