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.
There's no general reason to think hard things can't get easier.
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.
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.
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.
Certainly true in many respects. However I don't think learning programming is much easier now than it was in the 80s.
Back then I had to bicycle to the library to borrow a book, and hope that the accompanying diskette with the compiler in it was still working.
Programming is still programming. Maybe becoming a professional software engineer is harder, though.
An abundance of choice can actually make things harder.
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.
It was also what made demoscene competitions so interesting, there wasn't a web page explaining how to pull off those tricks.
It was curiosity and reading between the lines of those books that spiked out the curiosity to try out such tricks.
I wonder what else to call it. "Source code" is obvious and what everyone uses, but now I want something else to use.
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).
It's not.
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 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.
"we need to add certificats and raise the bar, quality over quantity"
Im not sure why that comment was delete, hn is becoming very authoritarian
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.