> The industry has been chasing the dream of making programming accessible for everyone for as long as computers have existed. This was the reasoning behind COBOL, BASIC, and Scratch.

Yes, and it's working. All of those projects helped. A child will learn far more in their first year of programming today than I learned in my first year of BASIC. I think that trend is accelerating and we are very close to the hockey stick part of the accessibility graph. There are a LOT of people who have at least dabbled in programming today.

> If it's Turing complete then someone can and certain would write spaghetti code.

Sure. And yes, some poor schmo will have to deal with it.

But most of the code won't be spaghetti code. Most of the code changes will just be string edits. Marketing has a vested interest in not breaking their pipelines.

I honestly think a little instruction goes a long way here. It's not that people won't be learning coding best practices, it's that you won't need a year of training up front just to get started. I'm not talking about eliminating the learning curve, I'm talking about making it shallow and linear.

> There's no reason why they couldn't just drag and drop such logic

Visual logic programming has been a mixed bag. It does work well for some very constrained kinds of programs, like shader pipelines and audio programming. But generally research into visual programming has not gone well.

Text has one very important benefit over visual programming: it's linear. That's nice because much of code execution is linear. It's actually a tree, but it's definitely not Cartesian.

Drag and drop is also not very intuitive for most users. It's an invisible affordance. It requires dexterity. And it's also not very constrained... You can drag anything into anything.

Most programming will be text. I don't think it will be pure ASCII but it will be linear text.

> Programmers aren't purposely trying to make their environments difficult

Of course not. They are trying to make it just easy enough for a full time professional to figure out and no more.

> High level business code that you sort of dismiss is the hard part. Knowing to gather requirements and codify them is the job a programmer

I think you're forgetting about some programmers. You know the kind... They just want something complicated to do. Like "rewrite the entire system using a custom memory store instead of SQL" and then they disappear into the wilderness for 4 weeks and come out with it finished.

Some requirements mean a lot of code to change. Some requirements require almost none.

What will happen is the "mostly talking, with fairly obvious code changes" part of the job will get absorbed into other roles. Marketing, support, finance, they'll just do that coding themselves. At least they'll do the patch and submit it for review.

And the other stuff... Stuff that's more about code than business needs, that will still be the domain of the professional programmer.

Current programmers will have a choice. Do I want to stay in mostly code all day and solve thorny problems? Or do I want to drop the "programmer" title, still do some coding, and move to marketing/support/finance alongside other "non-progeammers" who are doing a decent amount of high level programming.