This is the biggest mistaken belief of the programming industry.
Where we're headed is multi-level architectures. At the bottom is what you think of as "all programming". It's low level code, with manual deployment, using a wide range of fairly arcane tools. You need to be a professional to do it.
What is slowly emerging, which you suggest is impossible, is a layer on top of that. It is written in highly constrained code. You can't import random libraries, and you can't write spaghetti code, because you are writing in a highly constrained DSL. It's still real code. It's still a Turing machine. But you are working within a sandbox that your professional software engineering colleague built for you.
Most of us software pros don't think about development this way. We think we're supposed to be releasing finished apps to end users. But 20 years from now, we'll think of our job as releasing libraries for "non-programmers" to use. DSLs that are foolproof, which end users will string together using simple function calls and literals and nothing else. Languages in which it's very difficult to express broken ideas.
There's no reason the marketing team can't write this file:
post("miami", "Bienvenido a Miami!")
image("miami", "http://static.flickr.com...")
paragraph("miami", "We've gotten more requests for a Miami location than the rest of our...")
Well, there is a reason. It's almost certain that the programmers down the hall, like you, don't believe that a marketing professional could handle the "hours of thinking and planning" required to write that code. But again, they are all mistaken. Any smart, computer-savvy person could write that code after a few minutes of instruction.
But first you'd have to build that API, and a realtime preview, that is editable from a nice simple web app. You could do the "hours of thinking and planning" so that your colleagues could write the high level business code.
That's where this is all going. There will be a lot of programmers that work inside a sandbox like that, a few hours a week. Most programmers will work like that. And there will be a smaller number of seasoned pros will maintain those sandboxes.
> This is the biggest mistaken belief of the programming industry.
Actually I think what you're saying is the biggest mistaken belief in the programming industry. 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.
> You can't import random libraries, and you can't write spaghetti code, because you are writing in a highly constrained DSL. It's still real code. It's still a Turing machine.
If it's Turing complete then someone can and certain would write spaghetti code. Every constrained environment that ever existed for lay people to use ends up in the hands of frustrated programmers.
> There's no reason the marketing team can't write this file.
There's no reason why they couldn't just drag and drop such logic and prefer to do it as well. Most people have trouble understanding how to work with Turing complete languages to accomplish advanced tasks. Programmers aren't purposely trying to make their environments difficult -- in fact making everything as easy as possible has been the goal since the beginning.
> You could do the "hours of thinking and planning" so that your colleagues could write the high level business code.
Honestly that 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. It's a job in itself different from other jobs. It will never be a job for non-programmers and maybe not even junior programmers.
> 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.
> Some requirements mean a lot of code to change. Some requirements require almost none.
My point is ultimately marketing/finance/administration people do not know, fundamentally, what is a lot of code and what isn't. That's knowledge for programmers. https://xkcd.com/1425/
> What will happen is the "mostly talking, with fairly obvious code changes" part of the job will get absorbed into other roles.
There is no such thing as "obvious code changes".
> Marketing, support, finance, they'll just do that coding themselves.
Never happen.
> 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.
My software team develops all the software for the marketing, finance, HR, and support departments. They are deeply involved in the design of their products (some departments more than others) but ultimately none of them can or want to program. Even basic SQL is beyond the skills of most them -- although we encourage anyone with interest to do their own queries.
You massively under-estimate the skill and experience involved in even the most basic programming tasks. Programming, version control, deployment, database design, systems design, etc. These people have their own professions with their own issues to deal with.
> There is no such thing as "obvious code changes".
What about "there's a letter missing in this heading"?
> Even basic SQL is beyond the skills of most them
I would put SQL in the category of "advanced programming". It's declarative programming, which is not easy for beginners, and you can literally do any operation at all from any place in the code. There's zero separation of concerns.
> You massively under-estimate the skill and experience involved in even the most basic programming tasks.
What's so hard about changing a letter in a string on Github? Anyone who can send a text message could do that. To me, that's the "most basic programming task".
What's impossible about:
Hi Fred,
Thanks for noticing that typo! You can fix it yourself... The code is here:
Just click "Fork" and then "Edit" and make the change. The system will send
me a notification and if nothing is broken I'll merge it, and it should be
live within the hour!
Best,
Erik
> ultimately none of them can or want to program.
OK, so that's a cultural barrier. If you want to really lure people in, it will require a little more than an email like the one I suggested. I think to get people to bite, you need a few things:
1) Web-based editing, with instant preview (no downloading anything, no commands to type)
2) No repos, just editing single files
3) Very high ratio of domain-specific language to implementation language. Most programmers don't bother separating out their domain language (customer, sale, analysis, etc) from their implementation language (page, element, server, etc) You can't have a sidebar with node_modules, src, view, etc, it distracts people.
All this really requires is writing an extra layer of domain code that wraps your implementation code. It's not necessary if your code is only ever read by professionals so most programmers don't bother doing it. It's extra work after all.
4) Use only functions, function calls, and literals. No loops, no classes, etc. That stuff can go in the implementation layer, but you can't expose it. This also means no SQL, no CSS, etc. One language, three language constructs.
5) Separation of shared code from sensitive code and data. If you can do something like:
import "users"
users.delete_all()
... you're screwed. People will never feel safe making changes in that environment. You need real separation of concerns where the code being edited is mechanically separated from everything but the few functions you want to expose to people. Think of each source file as a custom sandbox for just one non-programmer employee.
Get all five of those, and you have yourself a changed game. Building all of those things is a bit of work, but there's nothing fundamentally mysterious about how to do it. It's just work that most companies don't do because you can just wall off your code within your professional programming team instead.
Where we're headed is multi-level architectures. At the bottom is what you think of as "all programming". It's low level code, with manual deployment, using a wide range of fairly arcane tools. You need to be a professional to do it.
What is slowly emerging, which you suggest is impossible, is a layer on top of that. It is written in highly constrained code. You can't import random libraries, and you can't write spaghetti code, because you are writing in a highly constrained DSL. It's still real code. It's still a Turing machine. But you are working within a sandbox that your professional software engineering colleague built for you.
Most of us software pros don't think about development this way. We think we're supposed to be releasing finished apps to end users. But 20 years from now, we'll think of our job as releasing libraries for "non-programmers" to use. DSLs that are foolproof, which end users will string together using simple function calls and literals and nothing else. Languages in which it's very difficult to express broken ideas.
There's no reason the marketing team can't write this file:
Well, there is a reason. It's almost certain that the programmers down the hall, like you, don't believe that a marketing professional could handle the "hours of thinking and planning" required to write that code. But again, they are all mistaken. Any smart, computer-savvy person could write that code after a few minutes of instruction.But first you'd have to build that API, and a realtime preview, that is editable from a nice simple web app. You could do the "hours of thinking and planning" so that your colleagues could write the high level business code.
That's where this is all going. There will be a lot of programmers that work inside a sandbox like that, a few hours a week. Most programmers will work like that. And there will be a smaller number of seasoned pros will maintain those sandboxes.