To my mind, this is analogous to textual writing itself vs drawing where text is an excellent way to represent dense, concise information.
The issue is that when you get into complex logic and number crunching, it quickly becomes unwieldy. It is much easier to represent logic or mathematics in a flat textual format, especially if you are working in something like K. A single keystroke contains much more information than having to click around on options, create blocks, and connect the blocks. Even in a well-designed interface.
Tools have specific purposes and strengths. Use the right tool for the right job. Some kind of hybrid approach works in a lot of use cases. Sometimes visual scripting is great as an embedded DSL; and sometimes you just need all of the great benefits of high-bandwidth keyboard text entry.
Regarding your point about complex logic and number crunching can be alleviated by using a 'Math Expression' node... which allows math to be written in textual form in a node.
https://blueprintue.com/blueprint/jt69wz7e/
Compare that with this bit of pseudocode:
function inputAxisHandleTeleportRotation(x, y, actingController, otherController) {
if(actingController.isTeleporterActive) {
// Deactivate teleporter on axis release, minding controller deadzone around 0
if(taxicabDistance2D_(x, y, 0, 0) < thumbstickReleaseDeadzone) {
sendEvent(new inputTeleportDeactivate(actingController, otherController);
}
else {
actingController.teleportRotation = getRotationFromInput(x, y, actingController);
}
}
}
1) It took me longer to create blueprints than it would have taken to write the equivalent code. I kept finding myself thinking "I could do this in 5 seconds with a couple of lines of code"
2) The blueprints quickly became unwieldy. A tangle of boxes and wires that I couldn't decipher. I find code easier to read, as a rule.
3) I didn't find it any simpler than writing code. A Blueprint is basically a parse tree. It maps pretty much 1:1 to code; it's just a visual representation of code.
I'd argue that 90% of it is just that they work out of the box. You download the engine bundle and you can start doing blueprints. Being able to write normal code requires you to compile UE from source, which is a non-trivial thing for any large C++ project.
I'm pretty sure if they embedded Lua or Lisp directly into the engine, and provided a half-decent editing environment in-editor, that it would meet with success just as well.
Blueprints are great for the material editor where everything is going to terminate in a specially designed exit node and there is little branching logic, but even for basic level scripting it is more messy than it used to be in the industry.
In the 1970s and 1980s I did many projects with huge schematics that you would spread out on large tables and focus on details while seeing the whole thing at the same time. It is an experience that can't be captured at all by a series of small pages, each with one to four boxes and lots of dangling labeled wires going to the other sheets. At that point you might as well just have a textual netlist, which made structural VHDL/Verilog become popular replacements for schematics.
Perhaps VR/AR will bring back visual hardware design?
I have written and maintained LabVIEW applications that exceed a 1,000 VIs. I would argue that such well-architected applications are actually easier to maintain for all the reasons that people expound functional languages for. The reason is that LabVIEW is a dataflow language, and so all the benefits of immutability apply. Most data in LabVIEW is immutable by default (to the developer/user). So the reasons why people prefer languages like F#, Elixir, Erlang, Clojure, Haskell, etc. overlap with visual languages like LabVIEW. I can adjust one portion of the program without worry of side effects because I'm only concerned with the data flowing in and then out of the function I am editing.
Somehow people form the opinion that once you start programming in a visual language that you're suddenly forced, by some unknown force, to start throwing everything into a single diagram without realizing that they separate their text-based programs into 10s, 100s, and even 1000s of files.
Poorly modularized and architected code is just that, no matter the paradigm. And yes, there are a lot of bad LabVIEW programs out there written by people new to the language or undisciplined in their craft, but the same holds true for stuff like Python or anything else that has a low barrier to entry.
That’s very insightful, and I think nails part of my bias against specifically LabVIEW, as well as other novice-friendly languages. My few experiences with LabVIEW were early on in my EE undergrad. At that point I had been programming for about a decade and had learned a ton about modularity, clean code, etc. The LabVIEW files were provided to us by our professors and, still being a naive undergrad, I assumed our profs would be giving us pristine examples of what these tools could do; instead, to my programmer brain, what we had was an unstoppable dumpster fire of unmanageable “visual code” that made very little sense and had no logical flow. Turns out it’s just because our profs might be subject matter experts on a particular topic, and that topic wasn’t “clean long-term LabVIEW code”. Later on I ran into similar problems with MATLAB code that our profs handed out, but by that time I had clued into my realization. At one point I was accused by my Digicom prof of hardcoding answers because there’s no way my assignment should be able to run as quickly as it did. (I had converted a bunch of triply-nested loops into matrix multiplications and let the vectorization engine calculate them in milliseconds instead of minutes)
Just like LabVIEW, my bias against PHP comes from the same place: it’s obviously possible to write nice clean PHP, but every PHP project I’ve had to work on in my career has been a dumpster fire that I’ve been asked to try to fix. (I fully admit that I haven’t tried to do a greenfield PHP project since about 2001 or so and I’m told the ecosystem has improved some...)
I lucked out with Python and started using it “in anger” in 2004, when it was still pretty niche and there were large bodies of excellent code to learn from, starting with the intro tutorials. Most of the e.g. PHP tutorials from that era were riddled with things like SQL injections, and even the official docs had comment sections on each page filled with bad solutions.
This is important because it shows that such things can exist. So the common complaint is more about people forgetting that text-based code review tools originally didn't exist and were built. It's just that the visual ones need to be built and/or improved. Perforce makes this easier than git in my opinion because it is more scriptable and has a nice API. Perforce is also built to handle binary files, which is also better than git's design which is built around the assumption that everything is text.
I think there's a lot of nice features to be had in visual programming languages with visual compares. Like I said in another comment, I view text-based programming as a sort of 1.5 dimensional problem, and I think that makes diff tools rather limited. If you change things in a certain way, many diff tools will just say you completely removed a block and then added a new one, when all you did was re-arrange some stuff, and there's actually a lot of shared, unchanged code between the before and after blocks. So it's not like text-based tools don't have issues.
We're just used to applying our software engineering skills to our textual languages, so we take it for granted, but there exists plenty of terribly written textual code that is just as bad or sometimes worse than the terribly written visual code. That's why sites like thedailywtf.com exist!
And then I set out to replace them with something "better". And during the process of replacing, I came to understand and form a mental map of the original system in my mind. And at some point I realized that the original system was actually workable. And it was easier to just use the old system now that I understood it enough.
Why? Can you give concrete examples of this? I see this sentiment a lot but never any particular examples.
When you start off with a prototype in a text-based language for something "simple", you don't extend it by continually adding in more and more input arguments and more and more complex outputs. You breakout the functionality and organize it into modules, datatypes, and functions.
Same thing goes in a visual programming language like LabVIEW. When you start adding in more functionality to move beyond simple designs, you need to modularize. That reduces the wires and boxes and keeps things simple. In fact, I liken well-done LabVIEW to well-done functional-code like in Racket, Scheme, F#, SML, etc., where you keep things relatively granular and build things up. Each function takes in some input, does one thing and returns outputs. State in LabVIEW is managed by utilizing classes.