Sure, we agree the code is not the important thing, but that's a very oblique point.

Where I disagree is that "removing the code" will help someone gain better understanding. It might help them dip their feet in and get at the core of what's important (hence MIT using scheme for its intro CS class for 30 years). However as soon as someone passes the beginner phase, the difficult thing is expressing the ideas succinctly and unambiguously. That's exactly what programming languages do.

A good analogy might be mathematics notation. You can explain basic math without any notation, but as soon as you get to more complex stuff you need the notation to help you reason about it and encapsulate the ideas succinctly. Similarly, graphical programming environments can do a ton of useful stuff (HyperCard is what got me into programming at the age of 10), but they will always always hit a wall (until true human-level AI anyway). The author definitely doesn't get that part.

I agree with you. Programming languages are dramatically simpler than human languages. Anyone can learn the syntax and grammar for a programming language in a few months (at the very worst). Not only that, but they reduce the amount of expression possible so that you have to be very precise in your descriptions. While beginners find this difficult to deal with, it's actually a massive help because there are only a few ways to express something and the compiler/interpreter often tells you when you get it wrong. Again, compare that to a human language where you have a huge amount of expression available to you and it is often nearly impossible to realise if you are being precise enough to describe the problem/solution well. A good way to demonstrate this is simply to try to write a computer program in your native human language, without restricting yourself to pseudo code. It's pretty easy to leave out important details and to end up with a huge mess of incomprehensible garbage.

There are many people who think that a visual language or some other abstraction will simplify the problem of coding. I really don't think so. While things like diagrams are great for helping people comprehend something, they are absolutely terrible for expressing something. Just look at how difficult it is to draw really good diagrams. Consider the fact that we have had cook books for hundreds of years, but almost none of them are described solely with diagrams. Words are how humans prefer to communicate.

I think we often fall into the same trap with programming languages or frameworks. We say, "Look how easy it is to do this trivial thing. It's 100 times easier to do trivial things with this framework than without it". We are completely blind to the fact that the framework makes it 100 times harder to do ordinary things and 1000 times harder to do complex things.

I think the author was saying something different, with which I agree.

There's a POV from which code is the details needed to get something done, and the less, the better. In my life, the less visible the code task has become, the more power I've gained. A couple of examples:

When word processors stopped needing to be told stuff like /b at the beginning and end of words I wanted boldfaced, it got better. I found the whole WYSIWYG thing enormously helpful. The portion of time I devoted to typography was released for improving content.

LabView made it possible for me to assemble data acquisition and control systems with drag/drop icons and drawing connections instead of coding a PID module and then a gain module and then a Kalman filter function and ... you get the idea. Less code to write, more stuff done.

By analogy: Today, I turn a dial to make a fire to cook my dinner. I turn a valve to get water. I drive a car to go places. Yes, I've rubbed sticks together, I've winched a bucket up from a well, and I maintained a horse for mobility when I was a kid. I'm pleased and empowered by no longer needing those skills.

In the same way, I look forward to the disappearance of coding as a prerequisite to creation. I'm immensely grateful to the people whose coding is making that happen.

This is a strawman. Coding has never been a prerequisite to creation. People were creative forever, and then computers came along and created new avenues for creativity. The vast majority of which is done with applications, and applications have improved by leaps and bounds every decade.

Only a very tiny portion of creative work requires actual programming, like demo scene programmers. Even video games and Pixar movies have far more artists then programmers. It's true that more and more programmers are required to extend and maintain the software, but the growth of the end-user base has far outpaced the programmers. The majority of programmers are implementing business logic of which they have minimal high-level creative input.

The things we can do with computers without code has only increased. Pontificating on how it would be better if we didn't have to write code is like someone who once used a circular saw pondering why can't artisanal wood carving also be done with simple straight-forward, easy-to-use tools instead of difficult-to-use hand tools. I mean its crazy how often we hear this refrain about coding as opposed to other professions. No one asks why can't we have a gadget to perform an appendectomy at home instead of paying a surgeon thousands of dollars, but for some reason people think that coding is somehow unnecessary magic which could be done away with by a bit of clever rethinking. But code is not some rube goldberg device designed to obfuscate and impress; code is a medium, like a blank canvas, or a sheet of typing paper, the only difference is it can control physical things. It is not one concrete thing with a specific purpose which can be optimized like a word processor, or a stove, or a faucet or a car. Less code doesn't mean a simpler world, it just means less of what code can do.

I appreciate the thoughtful reply, thank you. But it's not a strawman. That's when you advance an argument that wasn't at issue.

I supported the article's thesis, that fewer people will be coding in the future, and provided a couple of anecdata points from my experience. I don't think code is unnecessary magic to be done away with. It's essential magic that becomes invisible when done well, to everyone's benefit.

And to clarify, creative work isn't limited to the arts. The creative impulse is common and has multiple outlets. Engineering is every bit as creative as portraiture or sculpture or crafting LOTR on a ginormous graphics processor farm.

My observation is that as the need for coding has decreased due in large part to increased computational sophistication, it's gotten easier for a wider range of people to do contributive work.

Suppose you have something to say about climate change. If you need to model it, you have several global models you can run, without having to code FEA and planetary atmospheric physics from scratch.

Or pick an artistic field - I know a hand weaver who uses commercial software to visualize her designs before she heads off to her hand loom. She'll never code a simple if/then/else statement, but the (invisible to her) code in the app lets her do things she'd never have time or resources to try otherwise.

Even in your medical example - I'll guess that fewer than 2% of the surgeons who use a Da Vinci medical robot could do anything useful with the code that runs that system. And if learning to code the robot were a prerequisite to using it, it would be a failed product.

I like your thought of a device for home appendectomy. Why not, really? Ultrasound imaging, vital signs sensing, actuators for retractors, scalpels...and lots of invisible code to make it work well. Just the thing for clinics in parts of the world where there is appendicitis but no doctors.

Code may not be designed to obfuscate, but it does that to many who would otherwise be able to use computation to do something new and useful. I think the more sophisticated code becomes, the less it will be a critical skill for most people. Which is good. We'll be free to figure out the next important thing and work on making it trivial.

Once I figure out the difficult specific and rigid details, I just want the most productive way to communicate these details to the computer. Writing code is the most productive, because it is more exact and I am faster typing than drawing/dragging/clicking. For example, with Vim, I can do a quick "Ack def function_name" to find the definition of a function.

For learning purposes, Project Bloks looks great. But when it comes to real work, I'd happily learn the syntax, as it lets me be more productive.

I agree and I disagree at the same time.

For professional programmers, many people on this forum, the format that we use (text) is almost certainly the most efficient (yet conceived). It's made better with better tooling, of course, like IDEs that help us refactor, show errors in code as we edit, etc.

The author's point is that many more people will be programming in the future (hopefully) than are today. But not as professional programmers. For them, tools like (but not, of course, the same as) Project Bloks will be better.

Hell, we already do this today for ourselves. How many people get into the code-behind on GUIs regularly? Do you detail in code "button x will be placed to the left of button y, the center point between them will be ...". No, we often use some combination of markup language (XML-based like XAML, or something else) or visual designer (that may be generating a markup language version behind the scenes).

Then we connect the dots, the various objects to various actions or data sources, and off we go.

Just like 80% of my (early career) programming was really just gluing together a bunch of data sources for generating reports, much of what businesses need is in the same vein. Relatively (compared to the scale professional programmers like to think of our own work) trivial applications, that exist at a relatively high level (they're not writing a new DB server), connecting pieces together based off logical rules.

From a first principles perspective, it's me and the computer, and I want the computer to do something. My laptop has the following input devices: keyboard, mouse, webcam, and microphone.

I mostly use the keyboard and mouse. There are some places where the mouse is better than the keyboard. I was playing online chess today, and I like to drag and drop the pieces. It feels more natural and not that much slower than inputting the coordinates.

But when I was coding today, I needed to navigate through my code quickly. The mouse would have been much slower than vim's CTRL-D, CTRL-U, and /search_keyword, so I used the keyboard.

For the non-professional programmers, Project Bloks might be more like chess's drag and drop. It's more natural and not that much slower for simple tasks. I can see why non-professional programmers may like it.

How is Project Blocks different than the multiple (rather unsuccessful) failed attempts at graphical (even drag-and-drop) programming languages of the past?

its much faster to put together a functioning system than it was 10 years ago. For example in ROR, install devise and you already have a login system. I imagine things will keep getting incrementally easier / faster until one day we wont need a 'programmer' to do what we want.

google isn't unaware, I'll try not to put words in his mouth, but a google exec said something along the lines that we aren't very far from needing half of the programmers/ IT people we have today

> google isn't unaware, I'll try not to put words in his mouth, but a google exec said something along the lines that we aren't very far from needing half of the programmers/ IT people we have today

In one way, that's a scary idea (a lot of people will end up looking for work elsewhere). On the other, what programmer wants to do the stuff that can be automated away or done by a non-programmer? Or wants to reinvent the wheel because of NIH syndrome?

> what programmer wants to [...] reinvent the wheel because of NIH syndrome?

Almost all of them?

Hard to imagine, when I see all the stories about tiny modules in Node.js...but easy to imagine when I see how many JS frameworks are out there.

Still, so much of what we do these days is just tying together other people's libraries, connecting them together and maybe doing a bit of data conversion. My first step when I need to do something is to find out if someone else already wrote the software. Then I can just install+configure+move on to more interesting things.

Disagree that conclusion follows from quote. "Blocks" doesn't teach sufficiently deep thinking, and can only really solve problems within the domain of (foreseen by) the system itself.