It's an interesting question, but programming is not hard. One of the reasons that boot camps were so successful at getting people to attend them is that it makes people who thought they couldn't program realise that they can.
But the act of programming is not the only thing that a professional programmer needs to do. Understanding requirements, planning development, dealing with the complexity of large systems, communicating -- those are difficult. You don't need to do those things just to program. You can start your own project and build something that most professional people would call a "toy", but is still really satisfying for the average person. There is a limit to how complicated something can get if it is under a few thousand lines of code, and you are the only person working on it.
I find that most movements for simplifying programming are attacking the wrong part of the process. It's fair if you want to make programming more approachable, but it's already very simple. If your goal is to get more people able to do a good job as a professional programmer, then you should concentrate on being able to handle complexity in large systems, or being able to discover and reason about requirements in the system.
I might argue that building a bridge is harder now taking the whole process into account (just the metallurgy is vastly more complex); but they don't fall down as often. Which they often did in early railroad days thanks to hidden cracks in the metal that were both frequent and undetectable back then. But ordering a bridge to be built might be easier, now.
Specifying routines completely disambiguously will always be hard, but I do think techniques will come along to provide the equivalent of railings and safety nets while you do this; such as AI to query you about what you really want to happen, and to draw your attention to edge cases and unusual combinations of circumstances that you need to make a clear decision about.
Programming is much much easier now than it was in the 80s! It's been years since I actually had to write any code myself - computers do it all for us now. Amazing things, these "compiler" programs.
That's a very interesting way of looking at it. I always kind of looked at my preferred language's grammar as "code", but now I feel like I'm calling TLS SSL when I do that.
I wonder what else to call it. "Source code" is obvious and what everyone uses, but now I want something else to use.
But overall it's so much easier these days. Even if you're spoiled for choice, you can get the tools and documentation for free. Back then it was either the BASIC interpreter that shipped with your computer (QBASIC for me) or the assembler (debug.com) or paying big bucks to buy a compiler. I was lucky that my dad could obtain a PASCAL and a C compiler through his work.
These days you might have too much choice but back then for a kid like me, the choice was what was available in the local library. So not much choice at all.
Sure there is, that's why mastering a concept is hard and takes thousands of repatitions or hours to become masterful.
Similarly not simply building the same old bridge, because who the hell wants bridge 1.0 I want warp-bridge 20.0 now, requires I have a mastery of basic Bridges and additional pioneering topics currently of interest of which few individuals are experts.
I think this is a really great point. Many people always dreamed of making games and now a days there are make-a-game kits that enable people to do just that with almost no programming knowledge necessary. But now the sort of games capable of being made by such things are relics of the past. By the time you create tools capable of enabling anybody to do 'average' tasks at one time, those tasks end up being relegated to triviality with the net effect that you're basically treading water.
And similarly the explosive growth of the products of these make-a-game kits renders the skill almost entirely worthless. What would have been a very viable publishable product 25 years ago, is now considered shovelware. I think the only way this would end is if we somehow reached a skill cap in development (you've officially made the best bridge that's at all possible!), but if such a thing may exist we're certainly nowhere even remotely close to getting there.
I disagree. It's pretty easy to, say, find a suitable log, stand it up by the edge of a stream, and topple it over. It's more about the strength required than the thinking; and if it's a struggle, we have JCBs, chainsaws, etc. to help.
For something a little more robust, hire an AVLB. For more permanence, buy something like a Bailey or Medium Girder bridge.
Of course, I'm being facetious; but my point is that "programming" covers a vast spectrum. We don't teach kids to write under the expectation that they'll be modern day Shakespeares (or build Danyang–Kunshan Grand Bridges); we do it because writing is incredibly useful, even if it's as mundane as a shopping list on the back of one's hand (or a log over a stream).
If it is easier, it could be so because there's less inventing of new procedures and more following existing procedures (that is there's less "programming").
I remember learning to program in Logo on a Commodore 64 when I was in the third grade. Even back then, I was decomposing my code into functions, playing around with recursion, etc. 30 years later, I was presenting to my son's 4th grade class, and was getting reasonable questions on CSS, github, etc.
The basic concepts behind programming just aren't that hard if they're accessible to elementary school students.
Where things do get tricky is when you start to scale upwards in terms of complexity, volume, and duration of service. But even then, it's all too common for engineering efforts to overestimate the need for those things. That then leads to architectural choices that not only make the system more difficult to work with, but also likely fails to meet the initial targets.
I disagree, programming is hard from the perspective of understanding the problems that are needed to be solved.
I agree, programming is easy, if the language allows you to formulate code that is logical and doesn't bite you because of "undefined behaviours" or "implementation defined behaviours".
Logo was and is useful in providing you with specific conceptual patterns for writing code, but does not give the necessary abilities to provide solutions to problems via code.
One can learn the features of Calculus and how to solve Calculus problems. but it is a different matter to learn how to use it as a tool to solve real world problems. This is a different subject altogether. In my undergraduate days, oh so many decades ago, a common refrain from us engineering undergraduates was how often we would be taught something with no reference to how to use that tool for real world problems.
As the years have passed by, I have been pleased to see that in some areas, this disconnect between learning a tool and using that tool for solving real world problems has strongly diminished. There is some excellent material now available that goes a long way to solving this problem. Kudos to those men and women who teach these courses.
It's not. You need someone to patiently and properly explain concepts, though. This applies to any area, not just programming, but programming IMO lacks good teachers.
Comments by banned users get killed by software. Community members who think the comment shouldn't be killed can always vouch for a dead comment (if they have karma > 30) by clicking on its timestamp to go to its page, then clicking 'vouch' at the top. If enough users do this, the comment is unkilled.
Killed comments are visible to anyone with 'showdead' set to 'yes' in their profile. We never delete comments outright except in the rare case where the author asks us to.
But the act of programming is not the only thing that a professional programmer needs to do. Understanding requirements, planning development, dealing with the complexity of large systems, communicating -- those are difficult. You don't need to do those things just to program. You can start your own project and build something that most professional people would call a "toy", but is still really satisfying for the average person. There is a limit to how complicated something can get if it is under a few thousand lines of code, and you are the only person working on it.
I find that most movements for simplifying programming are attacking the wrong part of the process. It's fair if you want to make programming more approachable, but it's already very simple. If your goal is to get more people able to do a good job as a professional programmer, then you should concentrate on being able to handle complexity in large systems, or being able to discover and reason about requirements in the system.