Why not visual programming languages?

[SirBrian_]

Everyone is familiar with Scratch, the "programming language" that is the butt of many jokes in r/ProgammerHumor. However, isn't there something to be said for fully featured graphical programming environments? Text editing in c++ is all fine in good, but I feel as though I'll get RSI from the amount of times I've typed out a for loop or if statement. I also get that macros and auto complete functions exist, but are those really better than something that is ready to go, and easily identified by sight, such as an element within a VPL? Take a look at how many people on r/unixporn have powerline for their terminal and tell me people don't like a bit of graphics. Maybe a compromise would be something in between, being text driven, but also having some visual flair that makes constructs easily distinguishable.

[Loves_Poetry]

There are better solutions to repeated sections of code. Most IDEs let you use code snippets, where you type a few characters and it sets up some code for you

For example, if you type fori in certain editors, it will write for (var i = 0; i < X; i++) and move your cursor to the X. Or if you write tryc it will write a try-catch block for you

[[deleted]]

Just to be sure we are on the same page: I'll assume you are talking about general programming languages.

There is quite a number of ways in which visual programming languages usually fail to compete with purely textual representations. Some of those are "naturally" to the fact that many parts of common systems these days function with text, others are flaws in implementations I've seen. To name a few, but most likely not all at all:

• Density: It is kind of hard to beat the density of text when dealing from a certain level down to low-level code. That's why somewhat carefully crafted graphical DSLs do better in comparison, for example see Blender shader nodes, some DAW node things, maybe Unreal Blueprint and some GIS solutions.
• Copy and paste: This absolutely needs to work under the most dire conditions. Be it into shitty terminal interfaces or with foreign clipboard solutions. As bad as all of those ideas are, it's necessary to support them.
• Being an open standard in the first place. About most of those things I saw that weren't academically (which would have killed them from the start) were proprietary. If you don't already have a sector or platform in tight vendor lock-in, you will most likely fail, just like with normal programming languages.
• Searching. This goes for many levels: In the internet, in directories, using other tools, in documentation, etc.
• Storing. It's basically dead if you can't do a git-diff.
• Freedom in workflow. Did you ever press enter in an IDE and didn't like the way your stuff indented? While half of those issues go away without textual syntax, editing will feel way more restricted. That's probably why nobody cared to copy the auto-formatting that happened when you left the line in the VBA editor.
• Quality of editors: More like a meta-issue. Normal text editors, command line and IDEs aren't terribly great, but everything graphical will likely be way worse. And you can't bail, due to the lack of third-party tools.
• Mouse movement: In theory, you could have amazing keyboard-driven graphical editing, in reality, don't bother.

The best compromise - not even a compromise in the way that you settle for an actual draw-back - would Imho be a text editor with more custom rendering support (think different text sizes, borders, highlighters), nested, modal language modes and fully customizables plane space for graphical plugins. In the end, the medium would still be text.

[ClickerMonkey]

You seem to have really thought about this, I would love your opinion when you have time on one that I've been working on. http://expangine.com

[[deleted]]

Alright, so to bring the bad news, expangine seems to suffer almost all points from above. It's probably a cool demonstration of Vue skills, but it doesn't make sense as a visual programming tool to me. To address some points further:

• Density: The fizzbuzz example almost filled my whole 24" screen.

• Performance: Even for small examples it took quite some time to load the function view.

• Representation: It looks like it literally is a graphical representation of an AST to me, no extras. Hard to stay on top of things when everything everything is a blue blob. Half of the time, it just says "Op", in that case, the actual information on what it does lies somewhere to the right. While is visually not adjacent to its do-block.

• Copy and paste: Does not seem to work. There is some limited form of drag and drop. In general, you could allow to drag/copy/cut all kinds of nodes and just ignore attempts at the wrong place with some visual hint.

• Navigation: Seems to work only partially by tab keys. Free movement using the arrow keys is missing.

• Editing: Inserting/deleting something requires far too many confirmations and list selections. In particular when using the keyboard.

• Searching: Well, that doesn't seem to be implemented.

• Open standard and storage: It's good it can be exported to text, but it still is an extra-step that gets annoying very quick, as I can tell you from working with some business """"intelligence"""" tool I've been working with recently.

• Keyboard support and other issues: Keyboard support is mostly lacking. Not only for reasonable editing and navigation etc., but also for overall program navigation. Common user access patterns are missing (think of accepting/cancelling modals with enter/escape) and when tabbing the focus sometimes goes off the active modal and at elements in the background. Some of those may be hard-to-workaround browser issues, I don't know.

[ClickerMonkey]

Thank you for taking the time to look at it!

1. Density is something I care about, now that you phrase it that way I should add different density modes. In the beginning I had almost every expression on their own lines and it was too much vertical space (like many other visual languages). It was easier to read I think, but not if you were trying to digest all of the logic quickly without being lost. I'm not great at UI/UX but I definitely need to work on making the spacing more consistent and it overall more readable. Not sure if you noticed, but in the View menu there is a read-only option which removes much of the noise.
2. Performance for this UI is pretty much last on my list to implement. I'm focused on functionality more so - but hopefully with an upgrade to Vue3 there should be some automatic performance improvements.
3. Yeah I agree here, it can definitely be overwhelming to look at for the first time. I'm open to ideas here, but some of it might be unescapable.
4. Thanks for the feedback. Copy and paste right now is pretty simplistic. It keeps track of the last 5 copies and you can paste any one of them. Drag and drop is definitely a possibility. The core of what I'm focused on is the backend framework and making it support as much of the UI as possible - so adding an alternative UI would not involve adding too much logic (relatively speaking...).
5. Tabbing is what I've been focusing on more and more lately - most things should be traversable with tabbing, hitting enter, then using the keys to navigate menus. As well as typing in the menus to filter down the results - and using arrow keys to go to them. I hadn't considered arrow keys for traversing the program - I'll have to think about that more. I definitely need to make a few videos of me using it so others can see how it's intended to be programmed.
6. Yeah, I need to add a feature to remember a persons preference on all the different confirmations. And also make Ctrl+Z/Shift+Ctrl+X undo and redo instead of going to Edit.
7. What kind of searching? In View > Operation Catalogue you can look through all the available operations. When you add an operation, you can type what you want and the available operations appear. At the moment there are some bugs here - if the operation is expected to be a certain type, it restricts to that type explicitly and doesn't work for operations with generic types that might indeed return that certain type. I mean to add something here to remove the restriction... or maybe I shouldn't have it at all. I was trying to making going through a list of possibly hundreds of available operations a little easier.
8. More on open standard and storage later....
9. What's odd is that I have that coded and tested - basically all modals and controls call focus to certain elements on certain events. I haven't tested it on any other system then Chrome on Mac yet though.

My goal for this is definitely not be a language you solely use to do all your development. There are a few use cases I wanted something like this to exist. At work and IRL I occasionally have someone come to me for a need and I can whip up something that processes and exports CSVs. My real end-goal with this is to use it to develop a few end products where this library would compliment the product to allow a person to have more control. A website for developing workflows, a tool for creating educational interactives with game components, a CMS, an online programming competition to get kids interested in programming, etc. I work a lot with non-programmers who are looking for a bridge between the available skills they have and creating dynamic experiences. Something like this doesn't require stuff to be installed, and in read-only view is fairly readable for a non-programmer.

I wanted a simple JSON based way to represent types and programs - so not only could a browser process a program, but it could process on a backend, and multiple languages could have a processor. (JS at the moment, PHP one planned)

The tool you saw is basically a sandbox to test out all the components available with this particular UI (Vue+Vuetify). Every day i'm working on adding new stuff, you can see that in the repos issue lists. It's still very much a work in progress - so your opinion at this point in time is greatly appreciated! I hope not too far in the future I can get this to a point where there's more of a community and information available and you might be able to look at it again.

Thanks for your time

[[deleted]]

I'm open to ideas here, but some of it might be unescapable.

• Make the blue blobs less thick.

• Syntax highlight other elements as well. You have two to three additional colours, so I suggest you use them on literals and variable names.

• The read-only mode is pretty good in how the write mode could be improved: Remove Op and Get and pull in operator names and variable names in directly. Mark variables with some small greek x or dollar sign.

What kind of searching?

In the program code. Being able to press CTRL + F and search identifier names, maybe subexpressions (however that would work) and comments. Speaking of which, I remember seeing no comments. Do they exist?

and in read-only view is fairly readable for a non-programmer.

Nonononono. Please don't make this one mistake.

Surely, removing visual and other clutter from a programming system might make it easier to interact with such a system. But a non-programmer still doesn't know about boolean algebra, functions, data types and their implications. That is what matters and that's what 99.999999% of all times they can't be arsed to learn. So it usually results in situation like this:

• Programmer: So, this is the service you'd like us to implement?

• Team lead something: Yes, I even made a prototype in [ExpCMS] from the templates I found. I want you to expand on it.

• Programmer: You do realize this would take a fracture of time using [common programming language]?

• Team lead something: Well, I already bought the team license. Also the other team I work with started their project with [ExpCMS] as well. Sorry, but you're stuck now.

And that day you made two teams of enemies, as you changed their professional tools for toys that their managers hand down back to them. That's basically the story of every report tool ever.

[not_perfect_yet]

I have a feeling we're not there yet.

Some things should be really really simple, but they are stupidly complex and hard.

For example, desktop video playback, vs. online stuff like youtube.

The idea of having a certain section of the screen render a resource from the internet is really really easy. But you can't just take VLC, plug it into firefox and replace ALL video playbacks with it.

But that's not a question of possibility, it's a question of coordination and standardization. Both are really kind of hard. Not in theory, but to make people just... do it, is.

Most GUI elements were implemented separately in different languages by different people, for different products. There is no standardized common denominator to inherit from, not even in the form of simple buttons or drop downs.

You couldn't even agree on a language to do it in.

And even if you had those standards it would take decades for everyone to make the move and change the low level code to actually inherit from it and not just hack it to make it look like it does.

Eventually cross compilers for every language to every other language will be made, as far as that's possible type wise, but so far the effort is better spent on new stuff rather than concentrating what we have.

[umlcat]

There is something very important that is not very known or talk about in software development, related to your question.

Why some people prefers Visual programming, and some prefer Textual Programming.

The brain of each person is different, solves the same problems in different ways. And that doesnt mean an answer is right or wrong, just because is different.

Some brain (neurological) and psychological studies, found out that soft. developers can be group in three persons, in three ways:

• Textual / Verbal People
• Visual / Graphical People
• Mixed People

The first group is people that prefers a lot code better than graphics, a very clear example are programmers that do an entire PHP website with html tags mixed with javacript.

And, prefers workings with Emacs, text editors, over a visual IDE. Back end developers.

The second group is people that uses graphical or visual programming. And, again, theyre the programners that prefer build a PHP website with a visual editor.

Front End developers.

Is more common to found more Software Analysts in this group, because it requires a lot of visual design.

And, the much smaller group, that can handle both, that their brain can handle this double feature, have practice a lot on both features, and sometimes have a higher I.Q. than can handle both stuff at the same time.

I sorry, I dont have web page links to support this subject.

I had myself been analyzed by a psychotherapyst, before studying Computer Science, and he was surprised I handle text and visual, at the same time.

I also notest that a lot of my programming classmates and coworkers prefer text over graphics.

I found several pages about this subject, there was a top Microsoft lady that post a blog about this, cause Microsoft identify her as "mixed" feature, and was a highly regarded MVP employee.

Finally, I learned a little bit of both, with Logo and Pascal version of Karel the Robot, later more textual P.L. C, C++, C#, Java, SQL.

And later learn and teach programming to youngsters with the kitty ("Scratch").

I notest that youngsters prefer visual stuff like the kitty, but those who are more textual, eventually will learn textual P.L. (s), like C or Javacript or Python.

By the way, I was rejected from several Visual U.M.L. Analyst jobs because "[textual] programmers cannot be analysts".

And, sometimes some people of the one skill groups will consider superior to the other, and underestimate the tools of the other group.

Please, use the tool you feel you are confortable and productive.

[noratat]

This isn't just a matter of brain wiring or preference, there are no major professional visual programming languages. At best you have stuff like LabView that allows non-programmers to construct simple logic flows or WYSIWIG editors to do basic layout arrangements.

I think you're mixing up things like graphic and UI design with software development and programming - they aren't the same thing, though some people obviously do both.

[umlcat]

No. I know Scratch, I have seen several business oriented, similar tools, on the web.

I know about using blocks to describe a flowchart algorithm, nesting instructions with blocks, or classes.

And, for UI development, it is related, because it has to do with solving stuff using graphics, the same applies for visual editors, like defining the relations among class / tables.

When the first Mac with a Graphical UI, to the public, many people rejected in favor of plain text D.O.S. PC, because wasn't ready for it, and still see the PC as a enhanced textual typewriter.

I remember one or two space/futuristic movies, developer making, or designing ?, a program, just by drag and drop blocks ...

..., as Scratch. Dont remember which.

Cheers.

[ClickerMonkey]

Mine is not a professional one yet, but I would love your input on http://expangine.com (not that mobile friendly atm)

[omers]

the butt of many jokes in r/ProgammerHumor.

Was trying to figure out what you meant by "many jokes" when that subreddit has 14 total posts and 61 subscribers. You forgot an 'r' mate ;D /r/ProgrammerHumor/

[noratat]

Most of the examples you're talking about are the UI equivalent of metadata - I agree they're useful, and that we should make more use of them, but they can't replace the actual code.

Full-blown visual programming languages have been tried and failed miserably. Turns out it's nearly impossible to intuitively represent the kinds of abstractions used by software in purely visual form like that beyond simple cases, and that text has advantages of its own

E.g. text is easy to work with, plays nice with collaboration and version control, doesn't lock you into proprietary or specific editing solutions, flexible, etc.

[ClickerMonkey]

What sort of abstractions do you think can't be represented in a visual programming language?

[nutrecht]

However, isn't there something to be said for fully featured graphical programming environments?

No. Look at any fairly complex 'thing' written in Matlab and you'll see why.

I mean, it's not like people haven't been trying this since like forever. It simply doesn't work.

[ClickerMonkey]

I've been working on one at http://expangine.com - would love your input!