Hacker News Reader

> 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.

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.

The seeds have been "everywhere in the last couple of years" for decades now.

It's the programmer version of "flying cars are coming".

The best part is that there are actual working systems now.

It's been the case for decades.

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.

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.

> —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'm working on a school project using salesforce right now, and it's basically what you describe, with making a web application through a GUI. It seems like it's probably a good solution for a business that needs an information system without much customization required, since it does make assumptions that can be constraining. I didn't enjoy working with it; it's less fun than programming with text. And I'd tend to call it "application building" rather than programming. Warcraft III's modding tools are similar - they let you build a game without very much typing. (In that case, though, the GUI didn't sap the fun out of it - probably because there was more room for creativity in Warcraft.)

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.

You would tend to call it "application building" because like I said, if you are primarily using a GUI, its just not programming. By definition. By the way, I am not saying that there is no place for text in programming. I am just saying that the definition that it is only text is holding programming back.

That's the "curse of End-User Development" (akin to the "AI effect" [1]): as long as any kind of automation task is made easy enough that end users can perform it reliably, it's no longer considered a programming task. It happened to spreadsheets, retrieving records from databases through GUIs, publishing and styling blogs as you explained, or the mere possibility to copy-paste large amounts of content (clearly a memcopy loop operation, but nobody sees those as programming anymore).

* [1] https://en.wikipedia.org/wiki/AI_effect

I find this idea of a cultural problem interesting, and in my opinion that we program with plain text is essentially a completely arbitrary choice. That said, in practice almost all of the non-plain-text tools I know are some kind of special case tool and then you still need to write source code for all the pieces of the program that don't fit the mold of the GUI tool.

It's not as much arbitrary choice as inertia. When the first computer development tools were built the idea to use plain text made sense, and we've been stuck with that decision for more than 50 years. Now our computers are powerful enough so that this technical limitation can be overcome, but the cultural thing and lack of adequate tools are holding the change back.

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.

[1] https://en.wikipedia.org/wiki/The_Humane_Interface

> I believe, contrary to almost all programmers, that this is in fact fundamentally a cultural problem, as the author points, out, and NOT a practical or technical problem. I think the problem is more fundamental than the author suggests though.

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.

You're really arguing against a straw man or a few of them. In other words, I wasn't trying to say that we should create programs without using any text or by drawing. Or that we should communicate without 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.

For as long as I remember IDEs have had said drag-and-drop interfaces, usually centered around the coding of GUIs, and no one has said that just because an IDE has a visual form editor it's not programming.

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.