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.
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.
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.
It's the programmer version of "flying cars are coming".
Literally before PARC had their Alto nailed down, there have been visual programming languages where you draw and connect boxes in order to program.
And you should think really hard why (for the most part) we don't program this way today. It's not because we're just stubborn.
BTW, there are actual flying cars too.
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".
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 think there may be technical constraints in making such an interface customizable enough, though. Salesforce and Warcraft make a lot of assumptions about what sort of program you're making. An application-builder that's as general-purpose as a programming language sounds like it'd be really hard to build. (Although I'm not sure how much harder that is than just building something like Drupal.)
We also don't have a graphical way of describing behavior, that I know of. Even in tools like Salesforce and Warcraft, custom logic is shown as plain text (though Salseforce gives you some buttons to insert variable names and operators). It sort of makes sense to just use text, if the alternative is making people learn a new set of symbols.
The book ''The Humane Interface'' described a system that could use WYSIWYG in an environment that allowed general computation, and that book has greatly influenced all modern interaction design, but we're not still there because of all the legacy practices that are still important to the industry.
Prove it to me by explaining your complete point without text, in pictures.
On a more serious note, we use text to represent symbols, because symbolic coding is powerful and pretty much the basis of our civilization, long before computers existed.
Text is powerful enough that I can talk about "Mercedes S-Class car" by hitting a few buttons, instead of spending the rest of my day drawing a Mercedes for you.
Symbolic coding can be expressed via graphics too, but it remains symbolic. Say, I could draw the logo of Mercedes, then draw a symbol resembling a car, and I wouldn't have to draw an actual Mercedes car for you, but what's the benefit compared to typing it? It's again the same, only much less efficient. Egyptians used to do it like this, but they've since changed their mind about it.
If you'd represent a program as a visual graph of function calls this is still not WYSIWYG, it's just another set of symbols representing the same abstraction. When you run the program, what you "get" isn't a graph of function calls, it's something else entirely.
So it comes down to what is more flexible than text for representing symbols, and honestly I'd like to see anything better than text.
It's not just source code which is based on text. We're communicating right now via text.
The web is build on text ("hypertext"). Web search is based on text.
Look around yourself. The majority of communication is symbols, and most of it is text.
Obviously, text is going to be important for programming. What I am saying is that the definition that programming only happens when you are writing textual source code is wrong and holding us back.
Start with the idea of intellisense or autocompletion for method/function call names and parameters. If this happens inline in the text editor, we are still programming, right? What if my intellisense/help for parameters etc. pops up in a box on the screen? What if it is a dialog with a description of the method, and descriptions of each parameter? Now what happens if for each boolean or enum, I have drop downs or check boxes? Now what happens if I can drag functions out of a toolbox into my code window?
What happens if I can also drag entire components into my project window and connect them to my database structure editor? But now I can also type some code into part of the editor to create some custom functionality. Am I programming? What if I didn't have to type any custom code at all? Am I still programming? I didn't write any code, I just dragged and dropped, checked some boxes and connected some components.
You're the one making up the distinction and arguing against it.
The primary reason that not everything has turned into a drag-and-drop interface is that it's highly inefficient. It remains a fact that compared to manually hunting for class Socket in tab bars and scrollable lists, just so I can drag it and drop it somewhere, it's far easier to just use your keyboard and type "new Socket" in your code, especially with autocompletion at your service.
Fundamentally programming (or software engineering, web development, etc.) is defined by editing textual source code. That's the definition. WYSIWYG is not, by definition, programming. By definition, WYSIWYG is sort of the opposite of programming. Programmers are proud of their ability to create textual source code that is processed to create programs or output.
Think about a specific programming activity. For example, creating a web application. If, rather than using code, I use a GUI tool to define the fields in my database, create links between tables, define and style forms for entering and displaying the data, am I programming? If that's the way I build web applications, am I a programmer? What if instead I find a Go-based Object-Relational-Mapper, write some SQL scripts to create the database schema, use SASS to define the styles for my web-based forms, etc. Now, did I do some programming? I created the exact same web application with two completely different approaches. Using the first method, I cannot call myself a programmer (some may argue this, but the general impression most programmers will get, perhaps unfortunately, is that I did not do programming and am not a programmer). In the second method, I used much more effort and achieved the same effect, but I did it by writing textual source code. Therefore in the second case I am a programmer. The difference is simply that I wrote textual source code.
Now, I am not saying that WYSIWYG editors cannot produce complex computer programs, even ones that are exactly the same as those created in text editors, or that I believe that WYSIWYG should NOT be considered programming. I think actually we should update our definition of programming to include WYSIWYG, and I believe that old definition is the main thing holding back software engineering.
Its really as simple as that. Text = programming. Not text = not programming. That means we are stuck in the 70s forever. Its a cultural failure.