A Dive into Data-Oriented Visual Scripts w/ Code "Data-Oriented" Visual Scripting is a more "legible" way to understand code -- It is so successful for "non-coders" that it could even be thought of as an entirely different (data-oriented) language! However, some key components of a proper language (in terms of making it understandable to the recipient) are still missing in general (non-visual) coding that we don't yet have the foundation for proper legibility necessary for code (or even visual code) to communicate a clear message to the recipient. After all, coders are only "communicating" with a computer, right? -- Wrong. Our code communicates with other humans (and ourselves) as well. We need our code to be clear at-a-glance to other humans too. This is critical. Sadly, our current understanding of code structure revolves around fuzzy or unclear practices and "programming patterns" that apply to some languages (but not others) to help us understand our code. However, communication is more than just a series of self-referential statements. Even non-verbal communication has clear rules. This amalgamation of self-referential statements we call "programming" very much lacks any clear rules, causing most programmers to write their code using a "language" structure more akin to "run-on" sentences than sentences with proper pacing and punctuation that would ultimately help to highlight the statement of a clear and understandable main idea. Even non-verbally this is true. For example, if I angrily run up to you and punch you in the face, my pacing (the angrily running up to you) and my punctuation (the sudden punch in the face) should have clearly and effectively communicated the main idea to you. (That's right. I liked your face so much I just had to punch it!) Code: a Language? -- The Programmer's lie Most "elite" coders like to call the amalgamation of ideas made of endless self-referential code (because that's truly what it is: something to be deciphered) and tit-for-tat "programming patterns" their programming "style". However, at the end of the day, as hard as one tries, the fundamental lack of a simple-to-understand communication interface turns it into a nonsensical "run-on" sentence. In English, "run-on" sentences are a treasure-trove of communication errors. They tend to be separated by commas, an "and" or a "but", or just no periods, punctuation, or capitalization. In general, _any_ sentence can be a "run-on" sentence if there is no clear starting/stopping points or clear overall "main idea" of the sentence. Here is an example "run-on" sentence: I started programming a game but then I got tired; the experience sucked and I had to get some sleep, but I couldn't rest because I was frustrated with the fact that programming a game is more convoluted than I ever thought it needed to be, so I started studying a lot of game development tools and ideas and learned that they were inefficient; there are better ways to make a game than programming from scratch every time, but I still needed to sleep, so I finally went to bed, but I couldn't sleep, and then I got a glass of water to help me rest, but did you understand whether I got the water before or after I got in the bed? This is exactly what reading (and understanding) code is like to anyone who didn't write the code. Can you understand (at a glance) what the main idea is? -- A little? -- If there IS a main idea, it is so vague or entrenched in other unrelated garbage that it doesn't make any sense at-a-glance to anyone who just wants to know (in a timely manner) what the hell is actually going on. Sure, comments help, but can you imagine going back to that sentence and trying to interpret where I've randomly been inserting little notes and text snippets across this "sentence" just to understand where you need to look for the parts you need or what parts actually matter to the main idea, and to what extent -- or in what contexts they actually matter? The legibility of the entire idea flat-out fails due to the lack of structure, pacing, and clarity of the main ideas. There's a better way to write (and understand) code!! Firstly... VERBS can change programming for the better! To solve the run-on sentence issue with Data-Oriented Visual Scripting, we must first see how this kind of scripting is like a proper sentence -- and in what ways it is NOT. Basically, a data-driven visual script can be broken down into three key parts: A script should be a series of subjects, verbs, and main ideas. Together, these will define the _overall_ main idea (i.e. the thing you are trying to communicate overall). The OVERALL main idea (at least in the context of DOTS Visual Scripting) is the stack order, flowing from top-to-bottom (there on the right in the diagram above), with each block reaching out to the left to grab the context passed in by the "sentences." VERBS or SUBJECTS! -- Oh my! If you are observant, you will find that, oddly-enough, the left side has certain nodes that are not considered "verbs", yet they still seem to "do" stuff. This naive definition of "doing something" is the programming-equivalent of an "and" or "but" in a run-on sentence -- or, using another analogy, it is what the infamous "idea guy" in a game-development team "does" when he "does" stuff -- amiright? These "subjects" basically "do" one thing -- they create data (from the void or from wherever) (or conjure "ideas" from wherever, assuming we're using our "idea guy" analogy). This data (or "idea") is meant to be worked with later (via "verbs"). The "verbs" (in the middle, with the pretty colored icons), I call "operators" and "functions" -- because they physically DO something / work with the newly-created/conjured data (or ideas) rather than simply conjure it and pass it on. Because operators and functions actually CHANGE the data directly, they are considered verbs overall. The verbs are the most important part of understanding the overall "main idea" since they help you understand what is happening to each individual idea in the stack over time to see what is actually happening to the overall idea, leading you to a deeper understanding of the overall main idea. As a programmer, it is THIS part (the VERBS) which I care most about noticing while programming (and it is why only the VERBS get those fancy icons in the image!) But don't forget that the original subject matter (or "idea" generated by the "idea guy") -- that is, the actual data slot we modify or use later (the data slot which was also conjured from the void or pulled in from other sources) -- is still very important too (critical, even) -- since the conjured data gives the verbs a place for their work to start from in the first place! All in all, the subjects (idea guys' ideas) and verbs (the worker-bees work) determine the pacing (subjects) and punctuation (verbs) that helps to clearly communicate the overall main idea. SENTENCES are both pacing and punctuation All in all, the verbs (and subjects) define the main idea, and in Visual Scripting, proper visual-pacing cues (such as icons, colors, verb and subject arrangements in the graph) should always be present to make the main ideas clear. Additionally, in a graph like the one above, notice how much that big green ugly line helps to clarify the separation between subjects/verbs and main ideas. A polygon line like this is vital for the purposes of punctuation. Without clear punctuation, you risk running into a visual "run-on" sentence. This is even possible with nice, clear, icons and colors. Take a look at UE4 blueprints and see what kind of vomit unhinged use of color/functionality can do for ruining visual clarity. Pacing -- the lack of which causes this: DOTS Visual Scripting solves much of this with its "stack" approach (see the "main idea" section on the right in my thumbnail). Additionally, if followed by proper visual punctuation, even this graph can be salvaged enough to be given an understandable pacing: I bet you didn't think spaghetti-code could ever be semi-legible, did you? Sure, the spaghetti-strings still convolute things, but it's amazing how powerful a simple green line is, isn't it? The approach above helps to keep pacing of whole ideas at-once by conveying the overall intent of the verbs on the subjects that make up the main idea at-a-glance. These are made both clear and legible through punctuation, which leads to easily-digestible chunks of computing for humans and computers alike. Together, the subjects and verbs create and modify the data over time. When combined with good pacing and punctuation, we ultimately arrive at the nice, clear, easy-to-understand, overall main idea we had always intended. TL;DR I suggest DOTS Visual Scripting focus on making the ability to create legible, easy-to-read, "sentences" its focus (while designing the overall UX), as this will ensure we won't keep repeating the mistakes of the past in future generations of coders. I will clarify these "mistakes" in a future post.