I'll sound cynical, but when I read testimonials like this, about people struggling with learning how to program, I can't help but make the comparison:
Learning how to program is like learning how to use a hammer. It's useful, but it doesn't teach you how to build a bridge.
Writing a program that does something useful isn't hard. The hard part of software development is reasoning about requirements, architecture, performance, maintenance, security, user interaction, data modeling, algorithms, relational algebra, graph theory, taxonomy, semiology, psychology...
Software is a fairly new endeavor and touches many areas of human knowledge. To apply it well, you should seek this fundamental knowledge, more than wrestling language syntax, memorizing APIs or groking pointers.
The biggest problem in computer programming education is the pervasiveness of object-oriented design patterns. There is a subset of humans on this planet who find this incredibly structured way of thinking exhilarating. A subset of that subset are great programmers. Others are just pedantic fetishists.
There is another subset of humans who find upfront, structured design boring as fuck. Yet some of these people could be great programmers. If they find Python or Ruby before they find C++ or Java, they might have a chance to be a great programmer. But if not, they will just end up thinking the programming world is full of insane super-intelligent aliens.
Learning how to write a set of instructions (however high-level) and reason about its functionality is a special skill. It probably comes natural to you, that's why you're here. But it does not for everyone. This is something we should foster in people, even if they aren't inherently interested in current software engineering dogma and all of the other areas you mention. They can find their place in that world later.
I think learning how to wrestle language syntax and the glorious, consistent, harsh, and utterly fair grumblings of a high level interpretor are the best first steps in being a great programmer.
> There is another subset of humans who find upfront, structured design boring as fuck.
That's orthogonal to OOP, isn't it?
> I think learning how to wrestle language syntax and the glorious, consistent, harsh, and utterly fair grumblings of a high level interpretor are the best first steps in being a great programmer.
If you like the computer to yell at you, then strong powerfully statically typed languages are even better for you. Try e.g. Haskell.
Sure, you can do upfront design in any language. But you need to have experience to do upfront design. If you're new to programming, you should just hack around.
The other option is to read a Design Patterns book and treat it like religion. This is what happens to many new programmers who start with C++ or Java. You learn the patterns and you apply them everywhere, because that's what you were told to do. Some people like this, but many are turned off right away. I understand the point of things like Java. They make it possible for dozens of programmers to collaborate on a large project without stepping on each other's toes. But all of that abstraction makes no sense to a new programmer (at least one who is not a super intelligent space alien).
I don't see that risk in other programming paradigms, mostly because they are not as popular. But I also think something like functional programming carries a lot less baggage than OOP. It's easier to get the main concept.
Dynamic typing is easier on a newbie. They're just trying to put the parenthesis in the right place. There's plenty of yelling going on already. That said, something like Haskell which is less verbose probably wouldn't be so bad.
Yes, just hacking around can be useful for beginners. Dynamic typing like Python does (and not like PHP or Javascript) might be ideal for novices.
About design patterns: Lots, if not all, of the common design patterns for Java are just workarounds for weaknesses of the language, like lack of proper closures. So more capacity for abstraction would make them less verbose or invisible.
That is true, but when you start it is certainly the part that seems the hardest.
It's one of those things that seems almost impossible until you get the "aha" moment and then everything seems to get a lot easier. Then you try and solve more difficult problems and it suddenly gets hard again.
Learning how to program is like learning how to use a hammer. It's useful, but it doesn't teach you how to build a bridge.
Writing a program that does something useful isn't hard. The hard part of software development is reasoning about requirements, architecture, performance, maintenance, security, user interaction, data modeling, algorithms, relational algebra, graph theory, taxonomy, semiology, psychology...
Software is a fairly new endeavor and touches many areas of human knowledge. To apply it well, you should seek this fundamental knowledge, more than wrestling language syntax, memorizing APIs or groking pointers.