Re: LLM comparison
Mats Wichmann <[email protected]> Fri, 19 Jan 2024 10:54:35 -0700
| Newsgroups | gmane.comp.python.tutor |
|---|---|
| Message-ID | <[email protected]> |
On 1/18/24 18:43, ThreeBlindQuarks via Tutor wrote: > This is a really hard topic for me as I believe views often differ sharply on what is a good or best way to write software. long thoughtful post mostly deleted... > > Consider some minor task that can be done in some form of explicit loop... > Someone then suggests only babies or newbies use loops and suggest a comprehension. > Someone may then suggest some other vectorized approach ... > But some suggest you search the internet and find some module... Well, problem solving always has contexts. What's right for a beginner in a structured learning situation (as mentioned in this post somewhere) is to "make use of the tools you've already been presented" - such exercises are designed to reinforce what has been presented, not send you off on searches. Trying to solve a problem for work is always going to have different considerations, which include things like "can I actually use this existing code considering [list-of-possible-issues]" vs "is it just better to write our own". The wide success of open source software, which is now part of just about everything, is largely down to working out that it's generally just too expensive to write your own if someone already has a solution. > My point is even humans often disagree and give weird advice but an idea program may do better if all the parts are seen as an overall task and programmed accordingly. My belief is this depends a little on the scenario, but essentially understanding the entire problem, or understanding the architecture, or understanding the scope and interfaces of the subsystem you're programming within, are crucial to be able to be effective. The TDD approach tries to come at things from another direction: do very small things, first describing the desired behavior through a test, so you have reliable components others can depend on - but you still have to understand how to compartmentalize the problem to be able to do that, which means you need to understand the problem. So the trend I'm seeing - more through social media commentary than through being in the trenches myself, to be honest- is that there's already a subset of the community that believes that the traits of a programmer are morphing to "be able to effectively ask a copilot a question and then be a really good code reviewer" - much moreso than being a coder yourself. How in the world newcomers are going to develop those two abilities without understanding the big picture, which you're going to be even less taught to do if "writing the code" is not much of the equation any longer, I have no idea at all. _______________________________________________ Tutor maillist - [email protected] To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor