I saw something on twitter a couple of days ago, and I promised to write this blog post about it. As usual, I’m behind on all the stuff I want to do, so it took longer to write than I’d originally planned.
My professional specialty is understanding how people write programs. Programming languages, development environment, code management tools, code collaboration tools, etc., that’s my bread and butter.
So, naturally, this ticked me off.
The article starts off by, essentially, arguing that most of the programming tutorials on the web stink. I don’t entirely agree with that, but to me, it’s not important enough to argue about. But here’s where things go off the rails:
But that’s only half the problem. Victor thinks that programming itself is broken. It’s often said that in order to code well, you have to be able to “think like a computer.” To Victor, this is absurdly backwards– and it’s the real reason why programming is seen as fundamentally “hard.” Computers are human tools: why can’t we control them on our terms, using techniques that come naturally to all of us?
And… boom! My head explodes.
For some reason, so many people have this bizzare idea that programming is this really easy thing that programmers just make difficult out of spite or elitism or clueless or something, I’m not sure what. And as long as I’ve been in the field, there’s been a constant drumbeat from people to say that it’s all easy, that programmers just want to make it difficult by forcing you to think like a machine. That what we really need to do is just humanize programming, and it will all be easy and everyone will do it and the world will turn into a perfect computing utopia.
First, the whole “think like a machine” think is a verbal shorthand that attempts to make programming as we do it sound awful. It’s not just hard to program, but those damned engineers are claiming that you need to dehumanize yourself to do it!
To be a programmer, you don’t need to think like a machine. But you need to understand how machines work. To program successfully, you do need to understand how machines work – because what you’re really doing is building a machine!
When you’re writing a program, on a theoretical level, what you’re doing is designing a machine that performs some mechanical task. That’s really what a program is: it’s a description of a machine. And what a programming language is, at heart, is a specialized notation for describing a particular kind of machine.
No one will go to an automotive engineer, and tell him that there’s something wrong with the way transmissions are designed, because they make you understand how gears work. But that’s pretty much exactly the argument that Victor is making.
How hard is it to program? That all depends on what you’re tring to do. Here’s the thing: The complexity of the machine that you need to build is what determines the complexity of the program. If you’re trying to build a really complex machine, then a program describing it is going to be really complex.
Period. There is no way around that. That is the fundamental nature of programming.
In the usual argument, one thing that I constantly see is something along the lines of “programming isn’t plumbing: everyone should be able to do it”. And my response to that is: of course so. Just like everyone should be able to do their own plumbing.
That sounds like an amazingly stupid thing to say. Especially coming from me: the one time I tried to fix my broken kitchen sink, I did over a thousand dollars worth of damage.
But: plumbing isn’t just one thing. It’s lots of related but different things:
- There are people who design plumbing systems for managing water distribution and waste disposal for an entire city. That’s one aspect of plubing. And that’s an incredibly complicated thing to do, and I don’t care how smart you are: you’re not going to be able to do it well without learning a whole lot about how plumbing works.
- Then there are people who design the plumbing for a single house. That’s plumbing, too. That’s still hard, and requires a lot of specialized knowledge, most of which is pretty different from the city designer.
- There are people who don’t design plumbing, but are able to build the full plumbing system for a house from scratch using plans drawn by a designer. Once again, that’s still plumbing. But it’s yet another set of knowledge and skills.
- There are people who can come into a house when something isn’t working, and without ever seeing the design, and figure out what’s wrong, and fix it. (There’s a guy in my basement right now, fixing a drainage problem that left my house without hot water, again! He needed to do a lot of work to learn how to do that, and there’s no way that I could do it myself.) That’s yet another set of skills and knowledge – and it’s still plumbing.
- And there are people like me who can use a plumbing snake and a plunger when the toilet clogs. That’s still plumbing, but it requires no experience and no training, and absolutely everyone should be able to do it, without question.
There are non-professional people who can fix leaky pipes, and replace damaged bits. With a bit of work, almost anyone can learn to do it. Still plumbing. But definitely: everyone really should be able to do at least some of this.
All of those things involve plumbing, but they require vastly different amounts and kinds of training and experience.
Programming is exactly the same. There are different kinds of programming, which require different kinds of skills and knowledge. The tools and training methods that we use are vastly different for those different kinds of programming – so different that for many of them, people don’t even realize that they are programming. Almost everyone who uses computers does do some amount of programming:
- When someone puts together a presentation in powerpoint, with things that move around, appear, and disappear on your command: that is programming.
- When someone puts formula into a spreadsheet: that is programming.
- When someone builds a website – even a simple one – and use either a set of tools, or CSS and HTML to put the site together: that is programming.
- When someone writes a macro in Word or Excel: that is programming.
- When someone sets up an autoresponder to answer their email while they’re on vacation: that is programming.
People like Victor completely disregard those things as programming, and then gripe about how all programming is supercomplexmagicalsymbolic gobbledygook. Most people do write programs without knowing about it, precisely because they’re doing it with tools that present the programming task as something that’s so natural to them that they don’t even recognize that they are programming.
But on the other hand, the idea that you should be able to program without understanding the machine you’re using or the machine that you’re building: that’s also pretty silly.
When you get beyond the surface, and start to get to doing more complex tasks, programming – like any skill – gets a lot harder. You can’t be a plumber without understanding how pipe connections work, what the properties of the different pipe materials are, and how things flow through them. You can’t be a programmer without understanding something about the machine. The more complicated the kind of programming task you want to do, the more you need to understand.
Someone who does Powerpoint presentations doesn’t need to know very much about the computer. Someone who wants to write spreadsheet macros needs to understand something about how the computer processes numbers, what happens to errors in calculations that use floating point, etc. Someone who wants to build an application like Word needs to know a whole lot about how a single computer works, including details like how the computer displays things to people. Someone who wants to build Google doesn’t need to know how computers render text clearly on the screen, but they do need to know how computers work, and also how networks and communications work.
To be clear, I don’t think that Victor is being dishonest. But the way that he presents things often does come off as dishonest, which makes it all the worse. To give one demonstration, he presents a comparison of how we teach programming to cooking. In it, he talks about how we’d teach people to make a soufflee. He shows a picture of raw ingredients on one side, and a fully baked soufflee on the other, and says, essentially: “This is how we teach people to program. We give them the raw ingredients, and say fool around with them until you get the soufflee.”
The thing is: that’s exactly how we really teach people to cook – taken far out of context. If we want them to be able to prepare exactly one recipe, then we give them complete, detailed, step-by-step instructions. But once they know the basics, we don’t do that anymore. We encourage them to start fooling around. “Yeah, that soufflee is great. But what would happen if I steeped some cardamom in the cream? What if I left out the vanilla? Would it turn out as good? Would that be better?” In fact, if you never do that experimentation, you’ll probably never learn to make a truly great soufflee! Because the ingredients are never exactly the same, and the way that it turns out is going to depend on the vagaries of your oven, the weather, the particular batch of eggs that you’re using, the amount of gluten in the flour, etc.
To write complicated programs is complicated. To write programs that manipulate symbolic data, you need to understand how the data symbolizes things. To write a computer that manipulates numbers, you need to understand how the numbers work, and how the computer represents them. To build a machine, you need to understand the machine that you’re building. It’s that simple.
Testing.
Another test.
I just wanted to say how proud I was the day I got to “can fix leaky pipes” stage. (In programming, not plumbing. I had to call someone the other day because my faucet wouldn’t turn off.)
“To write complicated programs is complicated…To build a machine, you need to understand the machine that you’re building. It’s that simple.”
I think Viktor would not disagree with you, and I think his main point is that we can reduce the complications of writing complex programs by making it easier to understand the machine you’re building. His approach is to offload as much of what the programmer has to keep in her mind as possible by augmenting the programming process with more intuitive and opaque tools that show you exactly what is happening instead of having the programmer maintain the tower of abstraction and state in her head. It remains to be seen how much value and productivity can be gained for professional programmers who know their craft (I think it may prove to be valuable), but at least for beginners it seems to be a promising approach.
We have those. They’re called debuggers. But that’s not opacity, that’s transparency, and the price of making the machine more transparent is that you have to actually understand what you’re looking at, or else the tool is useless. Creating an IDE that could predict ahead of time what a program was going to do, how much memory it was going to use, how many FLOPs it requires to complete, etc. in order to make the process predictive and identify problems early is akin to solving the Halting Problem. Your machine cannot do this for you. Every abstraction you choose not to maintain in your own mind while working is one that will bite you in the ass later down the road when understanding it turns out to have been critical to your work. You really can’t have it both ways – opacity and ease of use or performance and reliability is the rule.
One of the things that was difficult for me to confront as an adult is that life is not like video games. Anything worth doing is very, very, very hard, and performing the same unchallenging tasks that you already know how to do does not “unlock” more complicated ones. There is no avoiding it: if you want to do something skillful, you need to work hard and learn hard to acquire skills; you need to put in your 10,000 hours. Better tools can increase your productivity, but they cannot take learning out of the equation.
“Every abstraction you choose not to maintain in your own mind while working is one that will bite you in the ass later down the road when understanding it turns out to have been critical to your work.”
+1 🙂
> with more intuitive and opaque tools
The problem is, we cant build such tools. Those which we build anyways tend to introduce even more complexity when shit hits the fan (when you need to do something that designers of the easy abstraction didnt think about).
Of course we can. We do it all the time. Once upon a time it was accepted that “real programmers” write things in assembly language (you still get this vibe from Donald Knuth’s books with their fake MIX assembly code). But later on, more user friendly structured programming languages like C and Pascal were created, and then even more friendly object-oriented ones like Java and C#. At every step, the amount of actual knowledge about how machines work is reduced, and in fact “programming to the metal” is actually *discouraged* these days. Yes, barring the development of strong AI we will never get to the Star Trek level of “Computer, solve problem”, degree of ease, but the idea that the tools can’t be made better and even more abstracted from machines isn’t supported by history.
I’m somewhat inclined to say that both you and Viktor are saying the same thing in different ways. There are different ways/levels/avenues of programming and they require different tools. It’s plausible that a whole lot more people could write a whole lot more sophisticated programming with tools like http://code.google.com/p/blockly/ or MIT scratch. Viktor wants a whole bunch of better domain specific languages. You acknowledge that all such things are programming. There is a vast continuum and I’d argue that there is a bit of gap in the tooling between text code and ridiculously specific DSLs like mail auto-replies.
Frankly, I hesitated to mention the visual programming languages in the prior paragraph because they tend to be embarrassments since they are so limited in domain. That is, scratch seems like an amazing tool until you realize that all you can do is move a sprite on screen (in a tiny box). And, yes, sprites on screen are amazing, but mail daemons, web browsers, and device drivers and others are essential programming domains for which sprites aren’t the optimal mental model.
I think many writers in this vein are starry-eyed from Star Trek-style computers, where you just have to tell it the answer you want and the computer writes the program itself that will give you that answer. Hey, if we went from the Padd to the iPad in 30 years…
That article ticked me off too. But to interpret it as favorably as possible: I think he’s arguing in favor of displaying the data by default, like in a spreadsheet or a debugger.
We can, of course, use a debugger already. Some people like to single-step through their program to verify new code, but it’s not the normal way to learn. Maybe it should be?
I learned by typing things at an interactive prompt (at first in Basic). It’s natural with a command line interface to have to type a command to look at data. But that’s pretty old-school.
Pingback: Visto nel Web – 47 « Ok, panico
Typo: his name is Victor, not Viktor. You could be misunderstood as mocking the guy, which would be out of place in an article like this.
Really? How’d I manage to mess that up. I remember thinking it’s an odd spelling.
I have no idea where I got that spelling from. I’ll fix it.
OT, but I have to write this. There’s a plumbing company in South Africa (I forget the name) that has the slogan “We repair what hubby fixed.”
In my defense, it was a really strange setup.
The article by John Pavlus is silly. The myth that we “all” can program is similar to the myth that we can “all” do mathematics beyond basic algebra and arithmetic. It is just that, myth. However, like most myth it makes for sensacionalist journalism of which we are in no short supply these days..
Pingback: Links 10/8/12 | Mike the Mad Biologist
While I do concur with most of your article, you’ll never convince me that HTML
or out of office replies are programming. HTML is analogous to writing a book in Word, out of office auto-responder is nothing more than configuration.
It’s not programming and if you tell the general public that it is, they’ll only be even more distraught when they get to see what a real program looks like.
Kevin, I agree, and let’s both agree not to even approach what “hacking” means.
I don’t know if MIT Technology Review is better than most magazines, but surely it’s almost always better to respond to the original essay (linked to from the article, or search for “learnable programming”) than to a journalist’s summary.
If we take the plumbing analogy, one could say that Victor is arguing that plumbing is broken, because the only tools we have are a plunger and a wrench. With such primitive tools it’s amazing that people learn much about plumbing, never mind that we can get running water in entire villages. If we introduced more sophisticated tools, maybe we could teach plumbing more easily and maybe even make professional plumbers’ lives easier.
I would argue that the examples in Victor’s essay are highly skewed, because (for example) everyone understands how a ball bounces, but expressing that in a normal programming environment is hard. Most of the time, in “real” programming, the domain is not nearly as well understood, so it’s unclear how you could add the kind of visual aids he recommends to a programming environment in a helpful way.
However, I do think there is truth to the general point that it’s hard to program “blind”, where you have to type hundreds of lines of code, possibly go through some “build” steps and maybe “deploy” somewhere before you can even see if it even works. Quicker feedback is almost always better. Feedback closer to the problem domain while you’re typing really would be helpful for everyone.
I know this is a very late reply, but I’d just like to point out (having taken those classes) that most people probably don’t know how a ball really bounces well enough to predict the height of an arbitrary test bounce (which would be about the same as writing a program to do the prediction for you).
There are a lot of discussions on the Apple discussion boards like this:
https://discussions.apple.com/message/19848405#19848405
I feel sorry for those guys.
How is using powerpoint and setting up scripts in mail, *not* programming? You are giving the computer instructions and it is carrying them out, it is just a high-high level language.
There was a discussion on the picAxe boards (PicAxes are small embedded controllers) where one person was glad he found the picAxe because they have a way to actually program the chips using flow charts!
And what’s the difference between configuring and programming? Certainly, the HTML renderer is a machine whose behavior is guided by its input source, which seems like programming to me. I don’t like to call it programming, neither, but… What’s the limit between programming and configuring?
Of course the techniques are pretty different, but it’s due to the complexity of problems solved by JavaEE, and not because there’s a theoretical difference between HTML and JavaEE. But this is what he’s saying, isn’t it?
Is it Turing completeness what makes something programming instead of configuring? Because I believe HTML+CSS3 is Turing complete (you can encode Rule 110), so you can solve any computable problem. How’s that not programming? Is it the techniques used? What makes something programming?
Wait. You mean you don’t want there to be a day when a person can just put a pile of pipes, boards, nails, and glass in near proximity of each other and surprise, you have a full house with plumbing!?
This seems like the silly thing that Microsoft (and others, admittedly) keeps pushing for, where programming should be boiled down enough that anyone should be able to click and drag a bunch of boxes together and have a complete solution to even the most complicated business tasks. It feels like they’re trying to put “real” programmers out of work – people who really do understand how everything works under the covers and such. What is your opinion of this, Mark, and everyone? It’s a bit of a cliche question, but I’m curious to know your opinions.
I’m pretty sure you know my answer already :-). Most of it’s already in the post.
Writing hard programs is hard. It always will be. It doesn’t matter how good the tools get – solving hard problems will always be hard.
I do think that there’s a lot that can improve in tools for all kinds of programming – there’s definitely a lot that we can do to make many kinds of lightweight programming easier (have you ever looked at some of the things people build with macros in Excel? That’s an incredibly painful and difficult way of doing what should be easy, but the tools just don’t make the grade); and I think there’s a whole lot that we can do to make building complex systems easier. But I don’t think that building complex systems is ever going to become easy – just like I don’t think that we’re ever going to see the day when people routinely design their own cars or their own plumbing.
The question is loaded, and I believe you’re looking at it through the wrong glass.
Of course that “they’re trying to put real programmers out of work” is completely false. By simplifying the development environment they’re putting programmers out of work; instead, they’re doing them a favor, allowing them to concentrate on actual problems to solve. There is no limit to complexity, so every simplification is not removing “real programmers” from the game, but increasing the interest of the problems they solve.
Really. If you like to worry about the stack pointer, if it increases or decreases, if it starts on high or low memory, or you like managing memory descriptors and paginating memory in 4kb chunks, or remembering where you should free the memory you allocated on a DLL on another thread, congratulations. Do it and be happy. But that’s not being a real programmer, that’s being a baker: your work is the same every day.
Real programmers like to do that once, and then forget about it and solve the next interesting thing. If it’s actually related to the problem to solve, even better.
Of course, by “by simplifying the development environment they’re putting programmers out of work” I meant the opposite!
That’s why I wrote *feels like*, not, “They definitely are, as a business strategy.” Please use the entire relevant quote if you feel like attempting to quote me. Much obliged.
Sorry, I didn’t use the entire quote because I don’t see that the “it feels that” adds any information. Of course anything you write is what you feels, that I took for granted. I don’t feel that, and I don’t know about the feelings of “it” XD
Adding “feels like” is meant to imply that I don’t really believe that it’s true, though I can see where the cornfusion would be. You heard me.
Ayayayay… another discussion about irrelevant details 🙁 How complicate is to argue on the net.
We all understand that, if you say “it feels like A” and I say “that A you’re speaking is completely false”, we’re speaking about if A is true or not, which is the interesting part, and not about if you believe it or not. That’s not the relevant part, and I didn’t imply that you believe it.
Hell, how careful one should be! Take it easy XD
A: It feels like people don’t like chocolate. What’s your opinion about it?
B: That “people don’t like chocolate” is completely false, because it’s one of the most consumed foods.
A: That’s why I wrote *feels like*, not “definitely people don’t like chocolate”. Please use the entire relevant quote if you feel like attempting to quote me.
B: !!!?
Can we close this little topic?
I had already closed it. My “cornfused” misspelling was meant to imply that. 😀
XD
One key point that’s often neglected; do these tools expand the market for programs, or do they simply take away jobs from competent developers? My guess is the former; the tool lets a business that can’t afford a competent developer use software to make their business grow. Once they’re bigger, they can afford a competent developer, and now have a need for one (to replace the ad-hoc tools from when the company was small with bigger tools for a big company).
If I’m right, then we should welcome these tools – it’s better to be worth 0.1% of a $20,000m market than to be worth 10% of a $10m market.
Yes, I thought that would be your reply, but certainty is appreciated. 🙂
You can probably already tell my opinion also, but for clarity: I am primarily a .NET/Microsoft stack consultant, and I HATE the stuff they do as far as “making business people be able to write code” goes. Not only does the code spit out usually smell like poo, but also the programs are most often riddled with bugs that the business people have absolutely no way to fix. It is then required for people like me to come in and build the system properly.
Huh. I guess in retrospect, the tools they build to do this actually keep me IN my job, not attempt to remove me from it. In that case, I love LightSwitch! (Just kidding.)
“Not only does the code spit out usually smell like poo, but also the programs are most often riddled with bugs that the business people have absolutely no way to fix. ” – This. Back when I was still designing webpages professionally as my primary focus, before moving on to more “challenging” tasks, I had a total hatred towards such things as Frontpage for two prime reasons: 1) they made everyone feel that they could design a GOOD webpage (whereas what they ended up doing was allowing nearly everyone to design “good enough” webpages and then complain later that “corporate webpages are worthless” – thankfully the latter has turned back around…) and 2) Because it was “popular” among the “less-skilled” they seemed to feel it was the best tool even after calling in those “more skilled” to solve a problem that they themselves couldn’t solve. I don’t know how many long discussions over why I would not use Frontpage or support Frontpage extensions I had with customers who felt that it “needed” to be used for “professional results” even though I always had the best success (and by far cleanest and easiest to understand code for the next guy to come along) going in and hand-editing the underlying HTML, perhaps with syntax/markup/reference tools such as HTML Assistant Pro (which still was a “code view” interface that primarily only provided syntax highlighting – indispensable in my eyes for catching “stupid coding errors” such as missing punctuation).
I’m still not sure that the problem is the one you (Michael and Kyle) believe.
Following Michael’s HTML example, I’m not sure that people are attracted to web development due to tools like FrontPage. Isn’t it the opposite? Tools like FrontPage are developed because people are attracted to HTML development. Usually companies don’t create the market, just follow the current, if you understand what I mean.
If that’s so, you would certainly prefer to cope with the horrible things that people do with FrontPage instead of the things they would do directly in HTML, wouldn’t you? XD
Agreed that it is not the tools that attract people to the coding. Obviously they are already attracted to being able to do it prior to the development of the tools to do so. The issue which I have is that the tools which are then created don’t actually allow them to do what it is they are really looking to do (or they wouldn’t have been coming to me to do it in the first place) but they DO give them the impression that it is the “right way” (and the ONLY right way) to do it.
As for the last question there, without FrontPage they would have come to me in the first place and not done anything with the HTML directly, or they would have been forced to learn how to do things “properly”. And while I’m all for exposing more people to actually being able to do it themselves, the more simplistic and abstract you make the initial approach, the more they are totally lost when it gets beyond what can actually be accomplished by that simplistic approach – and they have no basis to add to for moving on to a more complex method.
You miss the third option; without FrontPage, they might have decided that web sites are too much like hard work, and done without. While they were attracted to the idea of a web site, the cost of creating one would be too high to be worth risking.
Anecdotally, I have friends who have created first web sites for fledgling businesses in the cheap tools (FrontPage, 1&1 website builder etc). The expenditure ($100 or so) on the tools is affordable, and the time cost of doing a basic web site in such a tool is not unreasonable. In contrast, paying someone to do it, or learning HTML is too high a barrier to climb; had those been their only options, the business would not have a website at all.
Now, some of those businesses saw no real gain from the web site; they never spent more on web sites, as they didn’t see why they’d gain. Others found that the web site was bringing in business, and now saw a reason to invest in it. It’s that second group that got people like you in to help improve things; yes, some of them would get upset that you couldn’t just fix the FrontPage generated site, but others would pay you to redo it properly, as the site was too important to the business.
So, would you have preferred there to be less work out there, as businesses didn’t try having a website, or to have some awkward customers who’ve taken their first steps with a bad tool (FrontPage’s biggest limitation as compared to something like 1&1 website builder is that it doesn’t make it clear that there are limits to what you can do in FrontPage), and plenty of work out there?
Well, again anecdotally, I had plenty of “work” prior to FrontPage coming into existence, and in fact overall I think I had more “billable hours per hours worked” prior as well – because there was less unbilled time trying to show them how what they wanted done could not be done with the methods they wanted to use (or at least, if it could be, it would be a lot messier and not nearly as easy to maintain).
But, I wasn’t approaching it so much from the view of making more or less job opportunities available, but rather what the jobs ended up being like after FrontPage and similar tools came onto the scene. Gotta say that the advertising for those tools was top notch for their target audience – unfortunately when it did come to them wanting more than those tools could offer, they still felt that they were the best/only tools to make it happen. This is the problem with giving people simple tools for simple “machines” and trying to convince them that they can use the same tools for much more complex “machines” – even if it might be possible in the end, it will be a much messier and inefficient solution which makes further maintenance a nightmare. And I’ve never been one to subscribe to the “job security through code obfuscation” model 😉
Pingback: Everyone Should Program _and_ Programming Is Hard | Teaching Software Carpentry
Pingback: Ubiquitous Programming with Pen and Paper | Awelon Blue
Pingback: Software Carpentry » Why This Is Hard (Part Deux)
You need a certain set of skills, a kind of a passion for programming. If you’re not interested in that field, it’s unlikely you’ll get far. I remember when studying Mathematics we had a programming module and most of the people hated it. It was then that I first encountered it and I liked it, a lot. Still do
Linear execution of a program is unnatural when compared to the native processes of life and matter. The linear-sequential approach, however, is a most appropriate method of manipulating strings of symbols to decrypt encoded messages, which was Alan Turing’s original motivation for developing a theory of automated computation. Computation can also produce a desired string of symbols from any given string, by applying suitable Boolean and arithmetic operations, transformations and translations. Computation is possibly the best means with which to manipulate symbol strings, regardless of intrinsic meaning. Computation is the workhorse of data management, or data processing, as it is more commonly known.
Do we need yet another programming language to attempt to overcome the inherent limitations of linear-sequential data-processors, or is programming and computation perhaps NOT the best method to achieve the next stage in our drive to automate everything?
Automation, at its most useful, monitors and controls a physical process. It amounts to mechanical decision-making, assessing and acting on such questions as: does the process need correction to continue proper function, should a maintenance person be alerted, or should the process be halted to ensure the safety of personnel or equipment?
At present, the same linear-sequential faculty that is so apt at doing the grunt-work of data-processing has been applied toward management of physical processes. But data-processing is not an appropriate tool for process management, which is best handled in parallel-concurrent fashion. The data-processing solution, when applied to process management, becomes complex and always occurs after-the-fact, due to polling and instruction-fetch and -execution (software) delays. Using data-processing for process management is like making your lowest-rated assembly worker (who must be guided by explicit instructions every step of the way) suspend his labor and act as manager when supervisory duties are required.
I think this article misrepresents Victor’s position.
He doesn’t argue that programming is hard because we do it by typing code.
What he’s arguing, I think, is that it is worthwhile to strive for more direct ways of specifying programs. E.g. the way PowerPoint lets us specify animations. I think this idea is basically known as visual programming (Alan Kay calls it object-oriented programming) and it has a proven track record. Victor just seems to want to take it further. Object-oriented programming has often been sold as ‘programming made so easy that anyone can do it’. I think there is some truth in this statement, in that visual programming takes steps to avoids having to learn and type code when it’s not needed, and it does manage to attract people to programming who wouldn’t otherwise attempt it.