[Tutor] LLM comparison

[Mats Wichmann]

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.