> Programmers are proud of their ability to create textual source code that is processed to create programs or output.
I fundamentally disagree with this. You're acting like programmers/hackers do things in a textual way just to justify their existence.
Those GUI tools you posit exist—my Dad (who is technical but not a programmer by trade) used FileMaker to develop a little app for his church sometime in the early '90s and still to this day uses it. Does it matter that he didn't write any code? No. He produced a useful app and it's that end result that matters.
The problem is not that those tools don't exist, and it's not that "real" programmers look down on them just because they aren't textual. The problem is that those kind of tools are just fine, as long as you don't do anything complicated. Once you stray a little off the path of their standard use case then they crumble into a pile of leaky abstractions.
When you're dealing with textual programming languages it's generally much easier to stray from the beaten path since they are usually much less constrained. If you're writing a web app in Ruby, or Node, or Java, or whatever, you can do anything. It's more flexible, but at the cost of being more complicated. And the more complicated things get, the harder they are to shoehorn into a gui.
I'd love to see a gui programming language that was as open ended, as easy/quick to edit, and as easy to visualize as textual code in a text editor is, but they don't exist. And I fear they never will.
> —my Dad (who is technical but not a programmer by trade)
If he wrote it in a 'real' programming (textual) computer language you might have written that differently. You might have written "technical but not really a programmer" or something.
> Does it matter that he didn't write any code? No.
Yes, it does, because if he had you would have given him credit for being a programmer and acknowledged that his application is complicated.
I wonder how long it took your father to create that application with FileMaker. I would like to see how long it would take you to code it "from scratch" using your favorite "real" programming system.
> If he wrote it in a 'real' programming (textual) computer language you might have written that differently. You might have written "technical but not really a programmer" or something.
I wrote it the way I did because it's more nuanced than that. My dad can program. He's written assembly and knows some C. But he's not a programmer by trade—he's a hardware guy.
I think you will be pleasantly surprised in the next ten years or so. The seeds for such programming languages have been everywhere in the last couple of years or so, if you know where to look.
I agree that "draw and connect boxes" is an awful interface for general programming. But I've used it and it's terrific for some data manipulation tasks; and there are other visual paradigms that are not based on Boxes and Arrows (such as UML/model-based architectures, visual constraints, "Programming on Principle", whole-execution "rewindable" debuggers...) that offer substantial benefits even for some more general
- so there's people who ''do'' program this way, and find it better in some scenarios.
The idea is that, as computers are more powerful and can support visual tools that were impractical in the 80's and 90's, more programming styles can be created that aren't based on "one-dimensional stream of characters". Heck, even syntax highlighting and Python's "significant indentation" provide visual usability advantages over earlier language approaches. There's nothing inherently superior in the sticking to the old ways other than "it has always been that way".
The computers were strong enough to make visual tools possible even 20 years ago. It's the clumsiness and the limited expressiveness of interaction that limited the acceptance. I know: I was there. I remember reading Stroustrup who around the beginning of C++ wrote something like "we don't have to worry about ineffectiveness of headers in C++ because we'll anyway use visual tools soon." There were actually some tools. (http://en.wikipedia.org/wiki/Rational_Software "Rose 1.0 was introduced at OOPSLA in 1992") They stunk: http://c2.com/cgi/wiki?RationalRose
However, IDEs are alive and well, and browser DOM is stronger than ever - with "build your app" tools around each corner.
I doubted to put UML in there precisely because of Rational Rose and because UML didn't finally work as the basis for software architecture, but in the end that's still just a glorified C++ code generator - not an execution environment. Of course when your visual tool is a front-end on top of a traditional code it will have problems - you'll need a language that is designed from the ground up to work in a visual environment. And part of the reason why "visual environments" weren't created 20 years ago is because you couldn't execute the final program in visual form, in real time.
End-User development tools (rule-based like Agentsheet, graph-based like NoFlo or Blender graph editor, or even those based in traditional programming like Alice, Scratch or Code Combat) can be quite successful.
I fundamentally disagree with this. You're acting like programmers/hackers do things in a textual way just to justify their existence.
Those GUI tools you posit exist—my Dad (who is technical but not a programmer by trade) used FileMaker to develop a little app for his church sometime in the early '90s and still to this day uses it. Does it matter that he didn't write any code? No. He produced a useful app and it's that end result that matters.
The problem is not that those tools don't exist, and it's not that "real" programmers look down on them just because they aren't textual. The problem is that those kind of tools are just fine, as long as you don't do anything complicated. Once you stray a little off the path of their standard use case then they crumble into a pile of leaky abstractions.
When you're dealing with textual programming languages it's generally much easier to stray from the beaten path since they are usually much less constrained. If you're writing a web app in Ruby, or Node, or Java, or whatever, you can do anything. It's more flexible, but at the cost of being more complicated. And the more complicated things get, the harder they are to shoehorn into a gui.
I'd love to see a gui programming language that was as open ended, as easy/quick to edit, and as easy to visualize as textual code in a text editor is, but they don't exist. And I fear they never will.