Using ChatGPT for technical advice

[peterhinch]

tl;dr Avoid. Apologies if this is OT but I thought a word of warning was in order. Some might find some humour in the outcome.
I asked "Under what conditions is a circular buffer thread safe?" and received the following answer:

"A circular buffer is considered thread-safe when multiple threads can access it concurrently without causing any issues or data corruption. To ensure thread safety, the following conditions should be met:

1. Atomicity: The circular buffer's operations (e.g., read, write) should be atomic, meaning they complete without any interruption.
2. Access synchronization: Proper mechanisms such as locks, mutexes, or semaphores should be used to synchronize access to the circular buffer. This ensures that only one thread can access or modify it at any given time.
3. Buffer overflow protection: The circular buffer should have mechanisms in place to prevent buffer overflow when reading or writing at the end of the buffer. This can be achieved by tracking the buffer's capacity and using proper logic when updating the buffer pointers.
4. Thread communication: If multiple threads are both reading and writing to the circular buffer, proper synchronization mechanisms like condition variables can be utilized to allow threads to wait for specific conditions before accessing the buffer.
   By satisfying these conditions, the circular buffer can be considered thread-safe, enabling multiple threads to operate on it concurrently without introducing inconsistencies or unexpected behavior."

As an answer this grovels in the no-mans-land between "poor" and "lousy". It is hopelessly generic and misses the point that, under very specific conditions, a circular buffer can be thread safe without locks and mutexes. I had hoped it might identify those conditions...

The first point is OK but the rest, including the buffer overflow stuff, is pure waffle. All IMO, of course.

[stinos]

Completely agree. LLMs are a marvel and the'yre for instance awesome for higher level management talk and if you're lucky they can even produce proper working code, but I'm truly amazed by how seemingly large number of people do not realize what they cannot do (or rather what they're not suitable for, but still produce results for). Teaching you details of intrinsically hard and nuanced skills/crafts is definitely something they cannot.

[Josverl]

Agree , ill not disengage my brain when considering the answers. I like to write code that is mine , on know on what it is built.
to be open - in my experience the 4.0 codex models ( trained for formal computer languages - rather than for twitter/reddit are significantly more useful than the example provided above

So as a learning tool, I have been able to create functions to create and extend matplotlib plots in multiple steps that needed with just a little tweaking needed.
As matplotlib is one of the least loved languages according to the most recent SO poll, that is possible something that would be good to farm out to AIs.

[shariltumin]

LLMs are just tools. It would be a shame if we just wrote them off. None of us will want to write in assembler if we have the choice. We have compilers now. I asked ChatGPT these questions:

1. How to make circular buffers thread-safe
2. and how to do it in Python
3. how to do it without using lock

I got reasonable answers that I can work on as a starting point. Of course you should know what you are asking for and can judge the usefulness of the answers. I can ask about specifics in quantum mechanics and get answers, but that will be useless since I know next to nothing about quantum mechanics.

When it comes to LLMs, asking the right questions is the key. This is why prompt engineering is a hot topic right now.

[peterhinch]

asking the right questions is the key

I'm intrigued. How could I have better phrased my question:

Under what conditions is a circular buffer thread safe?

I did give the wording quite a lot of thought...

[jimmo]

Thanks @peterhinch yes I completely agree, and it's been a recent source of frustration to see examples of "chatgpt told me to do this so why doesn't it work?" (Both in MicroPython-related discussions but also other projects). The level of "confidently wrong" in the answers is very worrying.

On a related point...

I had a fascinating experience recently attempting to use "Cody" (from SourceGraph) as a tool to explore and understand the MicroPython codebase. Inspired by Stevey's blog posts:

• https://about.sourcegraph.com/blog/introducing-steve-yegge
• https://about.sourcegraph.com/blog/cheating-is-all-you-need
• https://about.sourcegraph.com/blog/cody-is-cheating
• https://about.sourcegraph.com/blog/all-you-need-is-cody
  (I have used the "Grok" tool that his team built at Google, so I knew this was worth at least checking out)

The key thing is that SourceGraph/Cody has is the additional codebase-specific context ("embeddings") which gives it a huge advantage over the generic tools like ChatGPT, and it was definitely a fairly magical experience trying it out on the MicroPython codebase asking where/how/why sort of questions. (I've been otherwise fairly uninspired by ChatGPT/Bard, this felt much cleverer)

Of course when you ask it questions that aren't specific to the codebase it still gives ChatGPT-style answers (and the answer I got about circular buffers was no better than your example).

It's very hard for me to judge whether mostly-correct-with-insidious-errors is a useful tool or not. I am worried that by sowing misconceptions while helping someone explore a codebase it might be overall more harmful, but at the same time the ease at which it gave most of the information was quite astounding.

To illustrate:

• It was able to extremely effectively describe the whole QSTR system. Some of this is summarised from the documentation but some it has clearly understood from the code. Interestingly the only mistake it made was it called them "QUeue STRings" (when the correct "uniQue STRing" is actually in the documentation!).
• It gave a very good summary of object representations A and B and the reason for the object representations but ignored the existence of C and D. When asked to explain C it completely missed the point (that floats are included).
• It had completely no idea about how floats work in MicroPython generally, and made up some total nonsense.
• It explained NLR extremely well, both how it works and what it's for, including some additional follow-up questions about the new jump callbacks feature. There was one detail that it gave about the PowerPC implementation that I wasn't able to immediately fact check that as far as I can tell it inferred from reading the assembly code.
• It was able to synthesise the basic structure of a new module, but missed some key details that I think would lead to a lot of frustration.
• It inititally told me that MicroPython does not support f-strings, but with some (pretty light) nudging it was able to give a high level summary of how they're handled (and where and the purpose of the various variables), but then confabulated some completely incorrect details about token generation.
• Using the "Explain code in detail" it gave some excellent explanations of individual methods in the arbritrary-precision integer code. This code is already well documented in a way that is quite helpful to someone who knows how this works, but Cody filled in the gaps well.

In the same way that ChatGPT/Bard's greatest strength seems to be as a summarising tool, at this stage I think it could be a great tool to help someone who can effectively fact check it write better documentation and comments. I only experimented briefly with it's "unit test generation" feature, and that showed some promise too.

[peterhinch]

@jimmo Thanks for those interesting links. I get it that it's early days - and that I'm the guy moaning that his chainsaw did a lousy job of getting the back off his laptop. Evidently it's a hugely powerful tool for grokking large codebases. Perhaps I've led a charmed life, but my work largely involved designing new systems rather than maintaining existing ones. Problems where I welcomed help were things like:

• API design
• Designing data structures
• Architectural issues (like the ringbuf query)
• Partitioning a system between hardware and firmware
• Designing communications protocols
• Predicting resource utilisation and performance
• Identifying possible realtime issues
• And so on ad nauseam.

If you get those right the actual coding almost comes as a relief.

However I do recall being in a team of developers pondering an early internet connection - and wondering at its application. I have no doubt that future iterations of AI will be able to help with these more rather nebulous areas. And some of those coding demos are impressive.