I've seen so many examples,where people,who spent decades in their fields become so cynical and 'know it all' type. This is almost universal across all fields.Fresh minds are always a good idea.
I have seen the reverse where so many junior engineers make soooooo many mistakes that are absolutely obvious to experienced engineers. That's why we review things.
I would also argue that programming advances so slowly for exactly this reason--we really don't respect the senior ones who know what they are doing.
In spite of what people think, programming isn't "new" anymore. A "know it all" programmer may be someone who has seen the wheel turn 3 or 4 times at this point. I would argue that programming hasn't really had a significant change since modern (read: assumes infinite memory and CPU) managed runtimes (Java, Python and Javascript).
Part of this is that the fastest way to a VC lottery winner is "social fad"--you want youngsters primarily because they are "plugged into the scene" and the programming is secondary. The number of times I have seen junior programmers try to solve the halting problem would make you weep.
I think we all have at some point. :)
Those of us who had some experienced people around simply found out sooner rather than later.
In what context?
What you describe is an example professors used during my education to motivate theoretical CS studies, i.e. you don't want to be THAT guy.
However, while this is true, I haven't yet seen many junior programmers on the job trying to solve the halting problem. I don't quite understand why that would be common. But maybe you are talking more about online communities and side projects?
> In what context?
The problem is that they don't recognize it as the "Halting Problem". It will be something like "Well, we can scan this thing to see if it does X or Y." No, actually you can't because "Doesn't terminate" is also an option. Oops. That's the Halting Problem.
In digital design, non-causal logic is a similar pitfall. Offline DSP algorithms can look backward and forward in time. If, however, you try to apply such a forward looking algorithm to a real-time system that needs an answer on the same time as the current sample, you wind up accidentally creating non-causal logic and wondering why your algorithm isn't working.
You may try removing whitespace, finding invariants, ordering the variables by type, converting for loops to while, tail call optimization, but your collegue always has a trick to make equivalent functions undetectable by your module. You were solving the halting problem. Instead, you should use CS knowledge and tell them it's impossible but they can have a non-optimal search. Perhaps, the fastest way to complete the task would be to score similarities between the functions' machine code or AST.