Block Coding - high-level, block-based visual programming

xyz

CodeSmile OR we can accept the fact that gaming is a growing industry that needs the new talent because companies have lots of open positions they can't fill, specifically in programming.

See that word you used there - talent. It completely dismantles your position and proves my point.

Nothing to be gained from "visual coding". Developing such systems is fool's errand. They're boring toys at best. It's just a delusion that some coding-minded people have about how non-coding-minded people could be magically turned into coding-minded people. In reality it can't be done, no matter how colorful and full of kittens your boxes are. There's no established educational methodology or serious body of research that supports it. In fact, there is research that shows the cognitive load is the same whether you're learning "visual" or standard textual coding.

CodeSmile You gotta have what it takes ...

You do.
And yeah, I totally am for gatekeeping. It's a good thing, if based on merit.

Tomcat

xyz See that word you used there - talent. It completely dismantles your position and proves my point.

??!! In what way exactly?

It seems that you are only willing to use the term “talent” in relation to programmers. You apparently do not apply it to people from other fields a priori. Even I am deeply shocked by this.

CodeSmile For the same reason we don't read Shakespeare to a 5-year old. Language can be beautiful and express complex emotions, but it needs to be learned and understood first. Parents adapt their language to match their kids' cognitive abilities automatically. Apparently we seem to forget about that once we become programmers.

There may be a homeopathic dose of reason in the insinuations of @xyz and @DaveTheCoder. The problem is that creating games requires programmer's thinking. And programming should be taught in school. In this regard, GDScript is very good — practically ideal as a “first language” (no comparison to BASIC). There are examples of artists mastering a primitive programming language and creating very interesting games. This is Ren'Py. I am surprised at how complex a game can be on it. But translating the entire GDScript into visuals is most likely a hopeless endeavor. The official developers refused to do this for good reason. When this refusal was discussed, it was suggested that the most reasonable option would be for the programmers of each specific project to visualize only the necessary parameters for that project. I find this interesting, specifically in the context of my project — I want to give talented artists the opportunity to create dynamic (interactive) stories (visual novels), and visual programming is ideal for this. But this is only within the project. Therefore, I will follow your project and possibly take something from it (if permissible). But, in general, I view it with regretful skepticism.

xyz

Tomcat It seems that you are only willing to use the term “talent” in relation to programmers.

The context of the thread is programming. I haven't used that word, the OP did. I used "inclination". By "inclination" I didn't even mean talent is the classical sense, it could just be a strong drive to want to do it. And I do think it applies to any field. People who don't have natural propensity for a field, shouldn't be pushed into it or lured by false promises and candy. Nobody benefits from that.

Tomcat There may be a homeopathic dose of reason...

Come on, there's more than a homeopathic dose 😃

Tomcat

xyz The context of the thread is programming. I haven't used that word, the OP did. I used "inclination". And I do think it applies to any field. People who don't have natural propensity for a field, shouldn't be pushed into it or lured by false promises and candy. Nobody benefits from that. By "inclination" I didn't even mean talent is the classical sense, it could just be a strong drive to want to do it.

I will even quote it in full. You are confusing or substituting the terms “talent” and “inclination.” And you are completely omitting the term “opportunity.” I may be a little confused by this wild language, but I tried to check them.

I gave an example of artists learning a simple programming language and creating high-quality, interesting narratives with fairly complex interactions (I could provide a link, but it's NSFW (all good things are NSFW)). So the idea of simplifying programming for game creation is quite productive. Why is it that only programmers who are terrible at art can create games, but artists can't? But translating GDScript into visuals seems like too much of a task to me.

CodeSmile The difficulty also lies in the fact that GDScript is constantly changing, and even after minor changes, a lot of rewriting will be required.

xyz

Tomcat So the idea of simplifying programming for game creation is quite productive

My position is that "visual coding" does not "simplify programming". The notion that programming gets simplified there is a pipe dream. Can you explain in what way it simplifies it and how can we measure the degree of that simplification?

Tomcat The difficulty also lies in the fact that GDScript is constantly changing

The language is not really changing much. The APIs are. And that's a different thing. But the fact that that poses a problem for "visual coding" just shows how clunky and inflexible it is as a way of telling the computer what you want it to do.

Tomcat

xyz Can you explain in what way it simplifies it and how can we measure the degree of that simplification?

Visual representation simplifies perception. Clear arrows instead of magic words — that's the whole idea behind visual programming. The question about the degree of simplification just confirms that you have no idea what we're talking about. “Professor syndrome” — a professional with extensive experience has forgotten how he learned and cannot understand that others may not understand his field.

xyz

Tomcat Visual representation simplifies perception.

Coding is not about perception. And you've yet to prove that the process of coding gets simplified in any way by using boxes and noodles.

The idea that "visual coding" simplifies coding is based on a fallacious, naive analogy that, duh, picture books are "simpler" than regular books ergo less text makes things universally "simpler". The problem with that analogy is that - coding is nothing like reading a book. Replacing text with "pictures" does not simplify it. Neither does replacing typing with clicking because programming is not about entering data into a computer either.

Besides, any box coding system still uses quite a lot of text. It's not really "visual representation". It's a form of textual representation with 2D layout control. Ironically, in many cases the amount of total text displayed by a box system is much higher than the amount of text needed to do the same thing in proper code.

As an example, try to step a component of a vec3 in Godot's visual shader and compare how much text you need to do the same with code. Here, let me do it for you:

vs.

step(0.5, myvector.x)

Do I need to count the characters as well? Oh, ok. The "visual representation" uses 500% more text.

On top of that, when you go beyond typical trivial examples, the node network can become an enormous visual mess and you need to spend additional mental effort on spatial management of your boxes. This can become significant as the complexity of the system increases. Not to mention how much screen estate is wasted on non-functional empty space inside those boxes.

You're insinuating that "visual coding" is somehow a prerequisite to learn proper coding. This is again fallacious. There is no such prerequisite. Millions of people have learned to program without ever seeing any "visual code".

Tomcat

xyz You're insinuating that "visual coding" is somehow a prerequisite to learn proper coding.

I have no such insinuations. You are making this up and attributing it to me.

On top of that, when you go beyond typical trivial examples, the node network can become an enormous visual mess

Yeah, this is a problem of visual programming, so I am trying to convey that completely transferring GDScript there is too difficult a task. However, simplifying it beforehand and limiting it probably makes sense. Well, it's definitely worth a try.

The idea that "visual coding" simplifies coding is based on a fallacious, naive analogy that, duh, picture books are "simpler" than regular books ergo less text makes things universally "simpler". The problem with that analogy is that - coding is nothing like reading a book. Replacing text with "pictures" does not simplify it.

In general, the analogy of picture books is close to this concept. Of course, a book with text undoubtedly carries incomparably more information, but to say that a picture book is absolutely unnecessary and even harmful is utter nonsense. Each approach has its own niche.

Here, let me do it for you:

vs.

step(myvector.x)

This is what I'm talking about — you've already forgotten how you learned, and the line seems easier to you.

xyz And you've yet to prove that the process of coding gets simplified in any way by using boxes and noodles.

Only practice can really prove this. “Practice is the criterion of truth” ©️ Everything else is theoretical reasoning.

xyz

Tomcat This is what I'm talking about — you've already forgotten how you learned, and the line seems easier to you.

It doesn't matter how it seems to me. The textual and visual entropy in the box example is objectively larger. Ask someone who've never seen either which one looks more complex. And it gets worse the more code you need to produce.

In any case, it doesn't really matter what anyone perceives as easier. The fact remains that any program worth its salt is written in textual code, not with boxes and noodles. You may argue that boxes are less scary for beginners in this or that way, but that's inconsequential in the long run of their knowledge acquisition process. Any beginner is better off ditching them as soon as possible. In fact that's often stated as the goal of box systems in the first place. So why start with them at all? They'll just hinder your learning by fencing you off from what's actually happening underneath. Simple code examples are in no way harder to understand than simple box examples that do the same thing. Both require the same amount of basic literacy and the same amount of logical thinking.

Don't worry, using code instead of boxes won't make you any less of an artist 😉

Tomcat

xyz Ask someone who've never seen either which one looks more complex.

I'm going to assume that you didn't conduct this test yourself. 😹

xyz

Tomcat I'm going to assume that you didn't conduct this test yourself. 😹

If you keep pestering me, I just might 😃

Tomcat

xyz If you keep pestering me, I just might 😃

Hmm… and I was sure that you were the one who was pestering everyone here, rudely imposing your deeply mistaken point of view. 😸

All decent progressive game engines have visual scripting as an option. But savages, of course, can program like in the Paleolithic era — with stone axes on cave walls.