"The Future of Programming" ...

Bold claim.

Until a new future of programming comes along.

In the end of the day it's just yet another tool.

Which is cool.

Considering that processing power gets cheaper and more powerful I'd expect our tools to become increasingly powerful.

However..

Great tools doesn't make you a master craftsman.

Clearly, you haven't actually watched the video.

The title is a joke. I don't agree with everything he says, but it's an excellent video and well worth your time.

I've worked at lots of companies that have experimented with visual languages. We always ended up scrapping them and going back to text. There are some really mature visual languages out there... But they dont have the decades of experience in building large scale software that C++ has. IME, they dont scale well enough, yet.

My preference in the short term would be a marriage of textual C++ and a visual environment, so I can deal with a function as a free entity, and not care as much about maintaining specific file layouts on disk.

There is no such thing as cheating in programming.

Though the fitness of the tool does not show until you have actually shipped your game.

It might be easy to get started, but how easy is it to produce a finished quality product without bugs or other unexpected behavior, having exactly all the features you want it too?

If you create a game with it then you are a game developer. Also just knowing a lot of technical jargon and coding in C++ does not make you a game developer.

Here is an article talking about why using a game engine rather than making one of your own : http://www.gamasutra.com/blogs/PeterAngstadt/20150505/242688/Im_Not_Rolling_My_Own_Tech_and_Neither_Should_You.php

This is not exactly what the OP asked, but it's still kind of related.

Clearly, you haven't actually watched the video.

The title is a joke. I don't agree with everything he says, but it's an excellent video and well worth your time.

I didn't watch it, until now.
It's a really great talk!
I agree that we should have that attitude towards programming that they had in the late 60's early 70's. It was a great time. The era of Mother of All Demos.

However, that doesn't really connect too well with the Original Topic: a visual scripting language and whether or not it could be the future of programming.
Or if it is "real programming".
They were experimenting with visual programming back then already.
I think that what we need now is an open mind and a willingness to experiment and stop being so cocksure about programming.

Hotline Miami was made with Game Maker.

That is all. Go forth and just make games!

So was gunpoint, which is great.

Fortune's tavern is a great game that was made in RPG maker. So was Charles Bakley's Shut Up And Jam: Chapter 1 Of The Hoopz Barkley Saga.

You're still learning some programming skills -- breaking down a problem into discrete steps, solving them, recombining for a result -- but the lack of scalability of graph-based programming generally means that there's a ceiling on the amount of complexity you will be exposed to, or could even express if you wanted to.

Good point. I have considered this too. They don't have every construct yet, but it does seem possible though. If we look at the basics of what a program really is, it would seem that graph or no graph, the building blocks are the same.

At the end of it all, it is all about I/O, and you only need one data type to make it work (Boolean).

I still think that it is all about open-mindedness. This is why I am exploring it and testing it, and helping as much as I can for them to see their vision. I still do wonder if textual programming will one day be the "last resort."

I still do wonder if textual programming will one day be the "last resort."

Unlikely -- graphs like this are really innefficient. They can be nice when each node can provide a preview of results to that point (as in a graph-based shader tool) for instant gratification/exploration, but that's mostly a boon for those inexperienced with the domain (e.g. artists creating shaders, rather than graphics programmers, or someone simply new to shaders). When you know where it is you're going, nothing so far beats text for efficiency, and until we can literally send our thoughts to a computer with enough precision to express complex logic, I don't see that changing.

I get the appeal of graph languages in specialized domains or for new audiences -- they're flashy, immediately gratifying, and remove some stumbling blocks like misspellings or entire classes of logic errors, all of which is really appealing; but they fall flat once you know what you're doing and all that stuff just starts getting in the way. If there's a better way than text (and I don't think there is) its not graphs.

Like Hodgman, if anything, I would want for (and suspect it will be) the next evolution of programming input to be essentially such that a program is a loosely-coupled database of independent entities (classes, functions, structs, etc), and which the editing environment supported -- kind of like the Light Table IDE concept (or at least original concept, its not clear from the current site whether they ditched that feature or not -- by appearances, they might have focused on real-time visual feedback on your program instead.)