If you think of a programming language as a set of tokens and production rules (a grammar), then can't every programming language have infinitely-many visual representations, including "pure text," "blocks/pipes" and "Jacob's Representation"?
Does it make sense to call a programming language "visual"?
What if I represent a C program by a sequence of smells... The translator device reads the text from start to end, converts it to a token sequence, and emits a different smell for each token. Does that mean C is a "smell-based programming language"?
If the tokens get read by a text-to-speech program, does that make C an "audio programming language"?
What about a different visual way to represent C programs (besides the usual text way)? Maybe we replace each token with a colored block, where each token has its own color.
Can't we dispense with the notion of a "visual programming language"? There are programming languages, and for each language, there are many ways to represent its programs.
- most text-based programming languages have no purely graphical counterpart.
- Most purely graphical programming languages have no purely textual counterpart.
- a graphic language is generally meant to abstract at a higher level and by doing so it has bigger trade-offs than a lower-level textual language (that's why most graphical programming languages are specialised and those that are too broad in their applicability domain generally fail to be useful).
Your suggestions kind of miss the point: it's not about the visual representation of basic tokens. If that's your goal, then of course you could represent any token and syntax with colour, sound, smells but it wouldn't solve any problem: you would still have to use the complete original syntax, and your colourful additions would not offer any improvements to basic textual representations of the code.
Graphical programming attempts to solve other types of problems. Generally, they try to hide some complexity behind a particular paradigm. Some are useful to help in learning because the building blocks can look like a concrete representation of something more abstract, like having a kind of C-jaw that represents a loop.
Other systems will help alleviate complexity using domain specific visual languages that would be difficult to represent textually: electronics for instance, or connection between musical equipment, or animations engines, etc.
Bottom line is that yes, they are all languages but while most textual programming languages are versatile and generally allow any level of complexity, graphical programming languages are sometimes better fits when the domain is much narrower.
They also generally operate at a different abstraction level.
Fine, but give me a program in any programming language, be it "text-based" or "purely graphical" and it's probably possible to translate it into a representation that's vice versa. (Problems arise when a representation is too abstract: ambiguity can occur.)
Program representations are like city maps. There's only one city, but there are many maps: the subway map, the map of post offices, the map of gas lines, the map of Wi-Fi coverage, and so on.
I will agree that different representations have different capabilities and use cases. However, text is also capable of great abstraction, e.g.
You're kind of stretching the definition of "language," though. Programming language grammars are defined textually.
Do you think, for example, that a (useful) pictorial representation of Haskell code can be derived simply from the language grammar?
Sure, the map is not the territory, but you can also say the language is itself the map, and the territory is something way more abstract, like "computation."
Perhaps you can take the semantics of Haskell and invent a graphical syntax for it, perhaps even strongly inspired by the textual syntax of Haskell. But it wouldn't be straightforward, and any obvious, straightforward attempt would probably be terrible.
In other words, I don't think it's obvious that there is a "deep structure" of programming languages that can be worked on directly in a wide variety of formats. Unless you count the AST as such a structure, in which case graphical programming is reduced to graphical tree manipulation (which admittedly is the path taken by many of these examples).
Dataflow languages (like the one I developed: http://www.nitrogenlogic.com/docs/palace/) seem like they would have a fairly straightforward mapping to/from a purely functional language like Lisp.
By the way, the more I think about this, the less I seem to know even what a "language" is.
Is Lisp a language? No, it's a family of languages, but even Scheme is a language known for its minimal grammar and its infinite extensibility. A common critique says that one programmer can't understand another's Lisp code because there's such a great potential for redefinitions and domain-specific syntactic extensions. If Lisp has a slogan, it's "code is data." Is Lisp a meta-language, or even an anti-language?
It's a shame people reject dataflow languages because they associate it with visual programming. Dataflow languages can be textual, visual, or a combination. It's good to see that NoFlo has exposed the textual side.
Like functional programming, one of the key benefits of dataflow programming is that it is inherently parallel. With the coming 16-core CPUs, GPU, and project like Parallella, this becomes even more important.
There are distinct differences between (1) visualizing a program (e.g. light table), (2) using a visual interface to generate the underlying (e.g. XCode Storyboard), and (3) a "language" whose primary or sole mode of "programming" is visual (e.g. LabView).
> Can't we dispense with the notion of a "visual programming language"?
In most cases I agree that label is a misnomer, but I think something like LabView genuinely does fall under the category of a visual programming language.
> What if I represent a C program by a sequence of smells... The translator device reads the text from start to end, converts it to a token sequence, and emits a different smell for each token. Does that mean C is a "smell-based programming language"?
If C was represented in an olfactory manner my code would be deemed a bio-hazard.
This is exactly why most 'visual programming languages' don't take off - because they fixate on a single means of repreaentation - which will never cover all use cases (and text representations can cover the same territory just as well) rather than doing what they should do - allow varied representations of programs.
Yes! All language, whether natural or programming, can have two primary structures: semantic and thematic (these are terms from Linguistics). Thematic structure (very roughly) refers to the effect of the writer, the medium, and the reader/s, which explains why one semantic structure can be represented in a variety of ways.
To me it's neither of them. I don't know how I'd call that, semantic .. ontologic ? The 'text' is as much an interface to the abstract model as the 'visual'.
When I see repls with sophisticated real-time output representation it's as much visual as dataflow programming by connecting nodes to an output sink.
Brett Victor's work is bringing them even closer since usually dataflow/reactive was used in mathematical settings (time varying scala or scalar arrays... image or sound) but he demonstrated far more the benefits in non linear logic (games).
It's the disconnected, char per char ascii, file saving, build time, run time tradition that creates an artificial segmentation.
If you really get to thinking, programming is all about abstraction. We talk about abstract concepts like functional programming, object oriented programming, structured programming, objects, functions, methods, inheritance, etc. But, in the end, it's all just playing around with stack pointers, instructions and malloc.
We abstract things and come up with constructs to represent these abstractions to make it easier for us to program a computer: to improve on our mental model.
So, we come up with different programming languages and label them by their approach. This is a functional programming language, this one is declarative, this one is procedural and this one is visual.
At its core, a programming environment provides a link between a formal system and some aspect of our world. You could think of a general purpose Computer as providing a link between any formal system and the aspects of our world that it ties int, but we can limit ourselves to programming environments for simplicity of discussion.
With that perspective, we can ask what representations of a formal system do we find easy to manipulate in ways that produce results that are significant for us (in a specific problem context).
A visual representation would certainly be a better match for a spatial problem domain (Sutherland's work, for example). Similarly, an audio representation can work well for an audio domain (ex: beardyman's realtime performance system he presents in his ted talk). Likewise, I'm quite sure a system for exploring cuisine art would match a "smell representation".
The notion of a "universal turing machine" guarantees that all of these representations can be mapped to that of a symbol stream. That is a mathematical result, but which representations appeal to humans involved in various kinds of work is not a mathematical question - it is a HCI question.
(1) Look at CPWCT, a visual programming language (based on the C programming language, and developed/used inside Programming Without Coding Technology (PWCT)
See this online movie to get quick idea without downloading the software : http://www.youtube.com/watch?v=461iVUl08mQ&list=PLpQiqjcu7Cu...
When you see this movie you will discover the difference between a Visual Programming Language like CPWCT and a text-based programming language like C
(2) When we use a text-based programming language, think of this using ( command-line / terminal ) of the operating system instead of using the GUI to do your tasks.
(3) Designing a visual programming language is an art (more complex than designing a text-based programming language) because the user interface of the visual language is more advanced.
(4) Using a Visual Programming Language, we can see the visual representation text in natural language (English, French, any other language) and we can change the visual representation and we can allow the programmer to change the visual representation (not easy to allow the programmer to change the syntax of a text-based programming language, we can do this, but the programmer will need to recompile the lexical analysis program, and it will be another language that can't recognize programs that are written using the old syntax, while in visual language we can allow this customization and we still open any programs create before or after this customization).
(5) We can add more dimensions to the visual programming language (like the time dimension). this dimension is not known to text-based programming language. you can move forward/backword during application construction process, and you can run programs in the past, you can see a movie of how to create the program step by step
No I think you're being sort of outlandishly ridiculous .... just to be honest. You would have us not allow for any sort of classification of programming languages then because they are Turing complete.
It's fine to classify programming languages. It's not fine to get confused between a programming language and a way of representing a particular program.
For analogy, there's only one true physical Earth, but there are many possible maps (representations) of the same area: one showing the temperature at the surface (using color), one showing wind direction at various points, one showing roads, etc. Which map is correct? Which map is best?
The project I work on has a custom querying DSL, and recently we have been working on a visual query builder for this language. So this is a very concrete example of a language with both a textual and visual representation.
Of course, keeping fidelity between both representations can be a challenge. Our design could be improved by being more diligent in sharing the same underlying model for both.
I imagine there are other cases like this, where you have a visual tool for building expressions for some textual language.
(Are there SQL tools like this? Seems likely there would be.)
>If you think of a programming language as a set of tokens and production rules (a grammar), then can't every programming language have infinitely-many visual representations, including "pure text," "blocks/pipes" and "Jacob's Representation"?
Yes. But that doesn't say much.
Visual programming languages don't just naively show some token graph. You can get that with a parser and a graph library for any language with half a day's work.
It's about the interaction models they explore, the levels of abstraction, and the tools they offer.
What you say is like getting rid of the notion of writing, since everything that can be spoken can be also written.
>Does it make sense to call a programming language "visual"?
It very much does. For a visual language it's syntax was designed as a set of drawn objects to be manipulated. That probably also influence its very semantics.
Quartz Composer: A Visual Language.
C: Not so much.
>What if I represent a C program by a sequence of smells... The translator device reads the text from start to end, converts it to a token sequence, and emits a different smell for each token. Does that mean C is a "smell-based programming language"?
No, it just means that it also has a smell-based representation (that is impractical and noone uses). On the other hand, visual programming languages were pragmatically designed to work in a visual environment, and enable coding by the manipulation of graphical elements.
>Can't we dispense with the notion of a "visual programming language"? There are programming languages, and for each language, there are many ways to represent its programs.
A visual programming language is not about a mere representation. It's about the core way the syntax is expressed to the programmer.
What you say is like "there are no declarative, logical or functional programming languages because everything is imperative at the assembly level anyway".
Well, the level at abstraction at which the programmer is supposed to work with a language (the language's syntax) is important, even if the code can be represented in a different way. Interfaces (in the UI sense) are important.
"What you say is like getting rid of the notion of writing, since everything that can be spoken can be also written."
I think this analogy works better for the original argument, as pretty much any sentence can be either written or spoken. There's nothing about English restricting it to be only a written or only a spoken language.
I think there is a balance to be struck between visualizing various aspects of a program (control flow, data flow etc.) and retaining the control available to developers writing their programs as text stored in files. It does seem strange in some ways that we're still dumping text into files in 2014. A given function might interact with classes and functions defined in 10 different files, and we can only view two or three files at a time.
It seems like programmers compensate by creating a mental model of their program as they try to memorize how it will execute. (The comic This is why you shouldn't interrupt a programmer comes to mind: http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-...)
I'm actually working on a plugin for Visual Studio roughly modeled off of Code Bubbles to see if it's practical to solve this problem. (http://codeconnect.io) I think text is the best way to express exactly what you want out of a program, but the way we're interacting with that text can be improved.
The problem ends up being that you're trading one form of cognitive load for another and it turns out that given our text-centric view of writing code, locality ends up having a lot of importance (which is lost in the model you're suggesting). There are lots of other issues with it at a practical level too. I've never seen an input model that works well with lots of disconnected little editors, for example. How do you navigate between them? How do you lay them out? What happens when the graph is disjoint? How do I get to some point in the flow of the program? What if I need multiple things that aren't directly related next to each other? How do you even determine relation?
After having implemented this in various forms about 4 times now, I'm fairly convinced this is one of those things that makes good intuitive sense, but bleeds to death from a whole bunch of paper cuts in practice.
The one case where this does seem successful though is in the step-wise debugging case. There's a very definite flow, locality matters a lot less, and debugging is an inherently mouse-oriented task - all the things you need for a zoom-based infinite canvas to work out.
CodeCanvas and Debugger Canvas are two projects we've definitely consulted while building this thing.
We've solved some of the practical problems you've described. The new C# compiler Roslyn makes determining relation fairly trivial, something that I'm assuming proved difficult in Clojure(script) and Javascript.
Many of the other issues are user interface/user experience problems that are better demonstrated than explained. Unfortunately, our demo isn't quite polished yet. We're showing it off at our school symposium in mid-March, so we should have something to show before then.
Would it be alright if I ran the demo by you when we finished it? Much of our inspiration for the idea came from CodeBubbles, Code Canvas and the original Light Table demo, so it's interesting to hear that you've decided against it.
One of my 4 implementations was the prototype I did at MSFT that became the debugger canvas :) Me and a few others built it after I saw the original Code Bubbles demo.
> The new C# compiler Roslyn makes determining relation fairly trivial, something that I'm assuming proved difficult in Clojure(script) and Javascript.
I had access to the language models then too, but the thing is relation is not always written directly into the code. This was the point I was making about locality. In a world with mutability, you can't really know what matters. We tend to cope with this by putting code that relates near each other (in the same file, in the same parts of a file, etc), but that relation isn't made specific in the call chain. It could be, and usually is, buried under several levels of indirection. The lack of locality really frustrated people, because the mainstream models we have for programming don't directly relate to flow and so it ended up being a square peg in a round whole kind of thing.
> so it's interesting to hear that you've decided against it
I've decided against it for the way we program now... :) Flow as a general concept is a very good one, and anything that can make that explicit would be wonderful. But we can't program with rampant mutation and callbacks and expect it to work out.
>One of my 4 implementations was the prototype I did at MSFT that became the debugger canvas :) Me and a few others built it after I saw the original Code Bubbles demo.
Haha yeah I've actually encountered that project. There are few things I've wanted open sourced as badly as Codeporium. A decompiler only gets one so far.. (You seriously come up all the place when it comes to extending the editor: http://social.msdn.microsoft.com/Forums/vstudio/en-US/e536bc... haha)
>I've decided against it for the way we program now... :) Flow as a general concept is a very good one, and anything that can make that explicit would be wonderful. But we can't program with rampant mutation and callbacks and expect it to work out.
> The one case where this does seem successful though is in the step-wise debugging case. There's a very definite flow, locality matters a lot less,
I think this has more to do with our conventional debugger interface being so horrible, that anything is an improvement. When debugging, I want my code ordered temporally in terms of how it is executing. Code bubbles give us that, but a 1D editor solution might still work better if the code can be dynamically reorganized.
> and debugging is an inherently mouse-oriented task - all the things you need for a zoom-based infinite canvas to work out.
It doesn't have to be, that's just what we have to work with at this point.
I love how the screen shot of labview is literally the shot NI uses from an article giving an example of what not to do [1]. Labview has its quirks but its not as horrible as that screen makes people believe
"In my experience with Labview you still spend a lot of your time arranging cables and boxes."
"I'm sure practical visual programming will be a reality some day..."
I don't follow how you get from the first sentence to this conclusion. Seems to me spending a lot of time "arranging cables and boxes" is pretty inherent to the whole visual programming idea.
What I'm saying is that I hope someone will come up with a way of making programming more visual without the tedious aspect of arranging cables and boxes.
When I see something like this, and comments debating the idea of it is a language/programming at all I think of this presentation: http://worrydream.com/dbx/ and the author of the link of this thread also uses one example that was used in the presentation.
We could have a bunch of different cool things to use for programming, but with a majority screaming "no, that's not programming" we kept ourselves from some really neat inventions.
> When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
I talk and think a lot about democratization of software development.
People I talk with who really want to program but couldn't get past coding really like the idea of visual programming environments where they don't have to deal with the compiler/interpreter.
When I talk with people who are experienced, they feel there is no advantage to programming any other way than writing code.
From my experience, we have not gone too far in improving the development of software for many many decades and Bret Victor does a good job of pointing this out. I think the way we code now, and specifically how we build out software frameworks, is flawed.
We engineer software frameworks that contain both mechanism and business "objects" when software frameworks should only contain mechanism.
Software frameworks should be coded to be used by non-coders: not by other coders.
Really, a domain agnostic visual language will be hard to develop when it is representative of how we code now.
None of those VPLs include those features; they would be too complicated for their target audience. They only resemble LISP in that they mostly are procedural (some of them are rule-based, but you can do rules in LISP also given its Turing Completeness).
There is a VPL based on LISP, I forgot the name, but you could definitely say it is LISP then.
The point was that saying these were all like LISP is like saying they are all like machine code.
A few years ago there was an MIT research project about a visual programming language where the program was represented as directed graphs. Does anyone know of such an MIT project from the early 2000s?
There were a few things that set this programming language apart from most of visual programming environments. First of all it was a proper programming language and not a toy project. The graph structure visualized recursion and re-use of variables very well. The code could be evaluated and edited at the same time by collapsing parts of the graph. You could collapse every iteration of recursion in the graph.
The most striking difference with normal programming languages was that all names were purely optional documentation.
Too bad I can't remember the name of this project. I remember seeing a presentation video of this project which got me really excited. It was a language by computer scientists, for computer scientists and not something done for kids or designers to get their first baby steps in programming.
Out of the ones on the list, AppInventor/Blockly/Scratch is definitely my favorite. There are different puzzle pieces for different syntactic structures, statements and expressions in particular. The puzzle pieces are colored by the type of the expression they represent. This makes it easy and obvious which piece fits where.
Something I wish was here was the spread-sheet style event programming interface in the old Clickteam programs, Multimedia Fusion/The Games Factory. I used to make so many complex games and other programs using that in the early 2000s; it was very powerful and I'm not sure why it never caught on in a big way.
Specifically: SCADE, AudioMulch, [BLOK], Shake, Max/MSP and Epecco. There are also some programs with visual programming elements: Voreen, Blender and ANKHOR FlowSheet.
In Lectura 7A of SICP[1], Sussman opens the lecture by talking about how programs can be thought of as character-stream descriptions of a wiring-diagram for some kind of machine. And he actually goes on to talk about the notion of visual programming languages (he didn't think they were a good idea). It's interesting to see these screenshots of visual languages. I must say that I agree with Sussman's reasoning for not liking them (difficult to edit them and they take up a lot of real-estate).
One that's missing, though, is Max/MSP, a visual programming environment focused around music & other media. It's used heavily by many experimental musicians and artists.
As much as I like playing with Max and PureData, I think they also highlight some of the many problems with the whole "Visual Programming" thing.
They don't play well with version control and are a nightmare to debug. The developer will also quickly hit a point where the visual nature of the tool becomes more of a hindrance than a help, when they're left drowning in a tangled mass of pipes and boxes.
I would really love to see a fresh take on this idea and an attempt to address some of the above problems.
Yes! The guy that made Max eventually made PureData (which is in the list). It's an awesome environment. Max (General) with MSP (Audio) and Jitter (Video) can do a lot of stuff, even control full lighting rigs + video, or even have a nice visual interface to an arduino. They recently integrated with Ableton Live too so you can use MSP patches as instruments. It's a great platform.
Definitely. Houdini is nodes everywhere. Nodes within nodes within nodes :-)
Could maybe add Softimage ICE to that list.
Also check out Grasshopper3D for procedural modelling.
Blender has a regular flowgraph for it's compositor and shading networks (and soon for particles, I think). Plus there's the logic bricks thing for it's game engine.
I'm glad some have taken the 3D tack. The neattools network was pretty imposing because it was so compact. Perhaps it would behoove the designers to pair a visual language with an oculus rift and 3D mouse to take advantage of the flexibility their medium offers over text.
It has Morphic with a snapshot of Squeak which is fair enough but it'd be nice to also include Self[1] which is where Morphic came from and which has I think a nicer implementation[2] of visual programming.
I don't understand why Squeak or Self (with or without Morphic) would be considered visual programming languages. Don't get me wrong, I think Morphic is a pretty slick system, but still...
Perhaps because it was not made quite clear what is considered to be a "visual programming language".
Based on what is in this list, though, it would seem to me that e.g. the combination of "Objective-C and InterfaceBuilder" could also be added to the list, which feels silly.
We also developed our own visual programming system for our free iPad app GamePress (http://www.gamepressapp.com).
Our system works like a flow chart of actions and events. Designed for tablets. It is fairly powerful as well, with lots of great additions being added.
It's interesting that there appear to be two main ideas: text coding but with less typing and more syntax highlighting (Squeak), and "draw a network" (LabView, Pure Data).
* Structured editing environments beginning with the Cornell Program Synthesizer [1] and including environments like Alice Pascal [2], which introduced code completion (I think). You could even include Scratch in this area, though it might be more about rules.
Maybe this style of programming never takes off either because of inertia or because the programmers themselves are wired to a certain way of thinking (I am going along the lines of programmers being more "right-brained").
If you want to see visual programming pick off, try giving it to people who are somewhat analytical but more creative (don't let programmers make your product successful). For example, designers or even artists.
Another good way to evaluate it is to see what a designer can do with a tool like: www.divshot.com
I have been singing this for a long time, but I think success in visual programming (for the web) will come when you can clearly separate the frontend and backend and let the magic happen then (meaning, see the results thereafter).
Writing code itself won't go away, but why write code for mundane tasks anyway? (Why write out the entire table/list display when you can simply take a generic one and modify it with some mod tools).
The thing we all need to do though is realize that writing a lot more code doesn't actually make you more productive (even though you may feel that way).
Also, with such technologies available, are programmers themselves not being luddites?
All experiences I have had with visual programming have been counter productive, (with the exceptions of creating GUIs). I think some things are suited to visual environments - things which need immediate feedback, other things are not.
Think about using Unix. For copying one or two files, or renaming the, use the GUI. Need to do the same with 100 files? I think most competent people would naturally go to bash, and write a for loops, or small script. For these things it is easier. (And I am fairly sure that most desktop environments have a had more time spent on them than most visual programming "languages"). Likewise Visual query builder in SQL can build a basic query fairly quickly and easily, but once you know the syntax well, it is probably a lot more efficient and powerful to use text.
The only non-text programming model that ringed a bell for me so far is subtext[1]. I still hope someone will extend it to a complete development environment with all the APIs needed.
I don't see the visual language that comes with Lego Education's WeDo robotics listed [1]. It's a great language for teaching kids to program robots, my daughter (who is five) will sit for hours trying to make new things with it. It's not always robot programming, mind you, you can have it play sounds and present images in loops as well as make robots move and sense motion.
I think it is better to call it model-based development rather than visual programming. Apart from those visual tools (e.g. Alice) which can be used to teach children the programming concepts, there are serious tools such as Simulink and SCADE (missing from the list) which are used to develop safety-critical applications in medical and aerospace fields. The reason to use these tools is to allow experts in other disciplines to specify an abstraction of their designs for computer.
Most of those languages even look like imperative (flowcharts) or object-oriented code (objects connected by wires).
If someone is in a such project it might be a good idea to show what are the benefits over looking at code beside subjective aesthetics.
For example ladder logic and LabVIEW look like a wiring diagram, which is excellent because their niches are electrical engineering. Minecraft is excellent as a game developing platform because you see the game you are developing right away.
Another one that is missing is Touch by Derivative (http://www.derivative.ca/). This is the language that Plastikman, NIN and Rush use to power the video projection, lights, smoke, etc in their live shows. It is not unlike Max/MSP, but has amazing video playback and projection, and supports lots of external devices.
I'm pretty sure the HyperCard screenshot is not actually a screenshot of HyperCard, but a screenshot of an early Mac control panel. In the link it seems like it's an example of what things looked like on the machine on which HyperCard was originally written to run, not HyperCard itself.
You can find plenty of screen shots of HyperCard applications (or rather, "stacks", as they were called) by using Google image search.
But HyperCard wasn't really a visual programming language. Indeed, it wasn't a language at all (the language is called "HyperTalk"). Anyway, HyperCard did allow you to design user interfaces in a slick visual way. But the code is purely text based. You can see example code at the HyperTalk wikipedia page
Was mentioned in the article, but often overlooked. Drakon is an old school FOSS diagrams-based visual-editor that outputs C (and Java, C#, Erlang...):
Very nice! I see you've got Simulink, but you could consider adding the associated state machine editor Stateflow: http://en.wikipedia.org/wiki/Stateflow
Very cool! My current project at my day job is a visual programming language designed for automated testing using our hardware, and apps. So its great to find some inspiration for ways to improve our product.
However, now it's time seriously think about programming robots. I want tell computer what I want to do and the computer shall figure it out by itself, including writing code.
It's not just you, I've heard this before, but I personally don't agree. Obviously it's very subjective and depends on how you learn/think - I'm a visual person so these types of environments have always made a lot of sense to me.
Also, don't forget that most of the complicated-looking ones are showing a large program - the equivalent of hundreds of lines of code. Just like you to see a portion of code on your screen at any given time, to work on these you'd zoom in to the relevant portion.
Does it make sense to call a programming language "visual"?
What if I represent a C program by a sequence of smells... The translator device reads the text from start to end, converts it to a token sequence, and emits a different smell for each token. Does that mean C is a "smell-based programming language"?
If the tokens get read by a text-to-speech program, does that make C an "audio programming language"?
What about a different visual way to represent C programs (besides the usual text way)? Maybe we replace each token with a colored block, where each token has its own color.
Can't we dispense with the notion of a "visual programming language"? There are programming languages, and for each language, there are many ways to represent its programs.