Visual Scripting vs Coding
Happy Thanksgiving,
First of All, I have been searching to know if Visual Scripting is a new thing that have been made for game engines.
Let me show you some example of visual Scripting 
the other thing is just regular coding like writing c++ code in IDE now I tried both of them but the question that I have been trying to figure out is, since I tried both of them it seems visual scripting is more easier, and more understandable for at least me I feel it makes sense when I connect nodes comparing it with when I am writing a code some thing like "Player controller" I will tell you how long it took me to write an enemy controller ! writing code for player controller in c++ it took me about 2 hours whereas it took me only one hour connecting nodes to make a player controller using visual scripting it , but even though it was an easy process and fast, I did not feel good about it, and I started to think more about what would be the advantage of writing c++ code rather than just connecting nodes? so here is the question: What are the advantages of writing code ? what are the advantages of using Visual script? What are the disadvantages of both of them? I know this advantages of Visual Scripting it is not as complicated as writing c++ code
Also would writing code be faster than the "already created scripts"(Visual Scripts)
Last question if you have to choose between both what would you choose Visual or writing code?
Note: I decided to ask the question here instead of game engine websites, is because here where I can find "Programmers" where in most games engine websites they all prefer the "happy way" as they call it which is (visual scripting) not the "sad way" which is (writing code)
I hope this time I did not ask some "bad" question that will result in too many negative votes :) be easy on me it is Thanksgiving ;)
Update: Here is some more information about the Visual Scripting that I am using in Unreal engine I got it from Unreal Engine website "The Blueprints visual scripting system in Unreal Engine is a complete gameplay scripting system based on the concept of using a node-based interface to create gameplay elements from within Unreal Editor. This system is extremely flexible and powerful as it provides the ability for designers to use virtually the full range of concepts and tools generally only available to programmers. Through the use of Blueprints, designers can prototype, implement, or modify virtually any gameplay element, such as: Games - set up game rules, tweak gameplay conditions, etc. Players - create variants with different meshes and Materials or character customization. Cameras - prototype new camera perspectives or change the camera dynamically during play. Input - change the player controls or allow players to pass input to items. Items - weapons, spells, pickups, triggers, etc. Environments - create randomized props or procedurally-generated items." I do not think there is such a thing like if you have to make something complicated you need to write code for it (my opinion)
Answer
If you look at UML, it is a modelling language that pretty much encompasses everything you can do with code, and it is great for modelling a system, however it falls short when used for program generation. Basically it takes a lot more diagramming, and a lot more diagrams, to describe really complex interactions than it does to write the equivalent code.
Take a simple 5 way switch statement. Easy to write, complicated to draw. Modelling different path-ways through a system can become very cumbersome, very quickly.
The drag-drop-connect model of code generation works very well when there is a simple data pathway, but once you are talking complex interactions between state machines, it becomes quite complex. In the past I've noticed these sort of Visual Modelling system end up with scripting on the connections to cater for the complexity, which often ends up making them more difficult to understand than straight code, and much harder to find where things are happening.
Finally, the higher level the language, the more trade-offs you have to make in terms of performance and control. So the more important these are, the lower the level of language of choice. If you are writing a highly time critical device driver function, you may end up writing assembler, while a high level menuing system for automation can happily be written in a scripting language. A visual language is a very high level language, so the trade-offs are likely to be quite high. However, the time to market tends to go down the higher the language level. So how much time and effort you want to put into something also becomes a factor.