> "Especially once you recognize patterns across syntaxes"
That's where my original point is - you can't do that until you have internalised (memorised) several syntaxes well enough that they drop down to automatic and you can step back and look at the patterns. If your attention is on Googling for how to write a list, it can't also be on the problem you're trying to solve. If you want to read Rust you're going to have to know what the ' does and what & does and it will be very slow going if you have to google it every time - but I'm not even sure you could google it, if you didn't have enough background to understand the concepts, and still pick it up on the fly. Say a Python programmer trying to google C++ "syntax" without having used anything low level, ever, isn't going to be designing a good C++ solution, at best they will very slowly write Python-in-C++-with-bugs.
Which raises a second point - spend some time in C# world watching people write Java-in-C#, they're both curly brace OOP languages but they are different and the runtimes and libraries and common styles and frameworks are all different. Step out to people learning Prolog and APL and "knowing the syntax" is useless, the ways of thinking and solving problems are very different to mainstream languages. You aren't going to recognise the Prolog pattern `foo(bar, Baz)` because it's not a function call and you can't google "what do the parens do" and make any sense of it being a term with a functor and arity which could be a fact or a goal or a data structure depending on the context. Here, learning/knowing just the syntax isn't sufficient to know the patterns. Or spend time with people coming from Bash to PowerShell and assuming the only difference is syntax, when it isn't.
That's where my original point is - you can't do that until you have internalised (memorised) several syntaxes well enough that they drop down to automatic and you can step back and look at the patterns. If your attention is on Googling for how to write a list, it can't also be on the problem you're trying to solve. If you want to read Rust you're going to have to know what the ' does and what & does and it will be very slow going if you have to google it every time - but I'm not even sure you could google it, if you didn't have enough background to understand the concepts, and still pick it up on the fly. Say a Python programmer trying to google C++ "syntax" without having used anything low level, ever, isn't going to be designing a good C++ solution, at best they will very slowly write Python-in-C++-with-bugs.
Which raises a second point - spend some time in C# world watching people write Java-in-C#, they're both curly brace OOP languages but they are different and the runtimes and libraries and common styles and frameworks are all different. Step out to people learning Prolog and APL and "knowing the syntax" is useless, the ways of thinking and solving problems are very different to mainstream languages. You aren't going to recognise the Prolog pattern `foo(bar, Baz)` because it's not a function call and you can't google "what do the parens do" and make any sense of it being a term with a functor and arity which could be a fact or a goal or a data structure depending on the context. Here, learning/knowing just the syntax isn't sufficient to know the patterns. Or spend time with people coming from Bash to PowerShell and assuming the only difference is syntax, when it isn't.