If UT were to add a new programming language what one would be best?

Go back and reread what I wrote. In theory your topics are great, but in practice your opinion is pie in the sky. If you actually had a grounded understanding of what it took to do what you asked for, you wouldn't be asking for it. So instead of threads that could be constructive, we get threads about someone wanting magic to happen to make their lives easier... supposedly.

 

Just because you want to improve Unity doesn't mean the ways you're suggesting make any sense or that you fully understand the implications of your suggestions. Quite a number of your threads are borderline nonsense.

Are you truly making a simpler language though? Or are you simply substituting one abstract for another abstract?

Apples and oranges. If this is your best example of simplifying a language then you may as well give up now.

 

Nobody uses VB any more though, about 13 years ago I did a part time course in VB 4 at Sheffield Hallam Uni, passed the course, created an app to randomly produce Lottery numbers, tried it out and won a couple of tenners!

There is "Visual C++" though, which I have no experience of but it seems like a more advanced version of VB itself, kind of OOP (Object Oriented Programming) based.

 

@RockoDyne Magic really, this is just applied computer science. Do you think the current GC is magic, no it's a less than optimal garbage collection system for games development that can trigger game or VR experience jarring hiccups that have been noticed by reviewers of AA unity games.

@Ryiah So just step around the idea that the Unity community wanting a visual programming language would inherently be the same as a new simpler syntax programming language for Unity.

And you missed the node complexity argument where a simpler language could have around a third of the visual nodes or code elements of C#.

And I'm sure that to die hard C programmers from the 1980's would think C# would be non-sensical, or Unreal game engines developers from the 2000's would think a mobile game engine was silly. But look at us now.

 

It was included in my statement about you not understanding the implications of your suggestions. Regardless of what you may think symbols in C# are not arbitrary. They do not exist solely for the sake of being there. They serve purposes now just as they served purposes for the predecessor languages of C#.

Removal of the semi-colon, for example, does not mean you lose the functionality (known as a terminator) that it represents with an alternative symbol. Some languages use a newline to represent the terminator. One downside to a newline though is that you cannot easily separate a complex instruction across multiple lines for easier reading.

Do not misunderstand me. I'm completely in favor of visual scripting languages for the reasons Epic Games introduced them to the Unreal Engine. Namely for those who are normally not programmers but want to glue some functionality together written by the programmers.

That said if someone is struggling to learn a text-based programming language then that is more an indication of their inability to be a programmer than it is an indication of a poorly designed programming language. After all the language itself is the easy part of learning to be a programmer.

 

@Arowx The simpler one example of your does not require a langauge change, it is simply a extension to the API. The more i think about the problem, the more i believe it is a problem that should be handled by the user based on the users usecase. The API provides the building blocks you need to create your own tools to suite your own use cases. Not everyone that needs to do a raycast needs to know of something is in line of sight, and maybe if someone is doing a line of sight check, they want to get more information if it is true, and thus should build their own method and reuse that. The same goes for node based programming, you can easily create functions or macros out of groups of nodes and reuse across the project, or you can write functions in code that get exposed as nodes.

 

The fact that it falls under computer science doesn't mean you have any clue how it works. You're bitching into the ether, hoping it will mean someone gets off their ass and delivers to you the perfect solution that you couldn't even define beyond some problems or features that triggered you.

 

No, I suggested a new editor, not a new language (unless you mean this in visual terms).

I propose nodes as a practical solution to an ongoing problem, that of lowering the bar, creating a less intimidating method of creating interactivity and an overall slightly less intimidating UI, a method for reducing complexity out of the gate for specific basic tasks. Your suggestions and arguments for other programming languages thus far seem to be simply solutions looking for problems.

This is riddled with incorrect assumptions. Total potential visual nodes is any number at all.

You've constructed a straw man argument by artificially creating complexity for a hypothetical system! At the same time ignoring the qualifiers I outlined. I'm not even sure how I'm meant to respond to this.

Sorry, what are you talking about?

Again, I don't get your point.

 

I can reduce your entire example to something like this:

Code (csharp):

1.  
2. enemy.setVisible(player.haveLineOfSightTo(enemy));
3.  

That's using C# and without inventing a new language.
setVisible and haveLineOfSightTo would be extension methods that take few minutes to write.

Also, if you turned that into visual scripting form it would be 3 nodes with 3 parameters.

 

Good point but I would say that example is 4 nodes, 2 parameters.

Which could be written as...

Code (CSharp):

1. enemy.visible = player.LOS enemy

5 nodes 1 assignment.

Note the reduction in brackets and lack of the archaic semi-colon;

I would say that simpler syntax is easier to read and if you want a visual paradigm goes hand in hand with a visual programming interface.

Why not bag two birds with one stone.

 

Actually, there are two parameters and two function calls. And there are few connectors.
four "nodes" total. In visual scripting form.

Code (csharp):

1.  
2.                                                      
3.                   ┌─────────────────┐       ┌────────────┐
4.                   │                 ├───────┤            │
5. player────────────┼hasLineOfSightTo │       │setVisible  │
6.                   │                 │   ┌───┼            │
7.                   │                 │   │   └────────────┘
8.           ┌───────┼                 │   │
9.           │       └─────────────────┘   │
10.           │                             │
11.           │                             │
12. enemy─────┴─────────────────────────────┘      
13.                                      
14.  
15.  

=============================================

This example is actually much harder to read. At a glance it reads as two different statements.
"enemyVisible = player.LOS" and "enemy".

Also the example does not tell you whether LOS is a method or a member variable, while in C#, because brackets are there you'll at least know that a function call is taking place.

To improve readability you'd need to do something like introducing special operator or form for assignments and getting rid of ability to have methods on objects.

==========================================

Actually, why did you switch from show/hide to .visible, hmm?

Try writing my previous expression in your "basic" form. It'll turn into:

Code (csharp):

1.  
2. enemy.setVisible player.LOS enemy
3.  

^^^ Are we passing player.LOS and enemy into setVisible, or are we passing result of player.LOS into setVisible?

Or, even better:

Code (csharp):

1.  
2. setVisible enemy LOS player enemy
3.  

^^ How many function calls are there? Which one is a function, and which one is a variable? Which function takes which parameter?

Meaniwhile, in language that has brackets and commas:

Code (csharp):

1.  
2. enemy.setVisible(player.LOS(enemy))
3. setVisible(enemy, LOS(player, enemy))
4.  

See? Brackets, braces, commas and semicolons exist for a reason.

For fun, here's common lisp form:

Code (csharp):

1.  
2. (set-visible enemy
3.        (have-line-of-sight player enemy))
4.  

No commas and semicolons, but by definition first atom in a list must be function call identifier. So, no ambiguity, despite having whitespace-separated arguments.

 

Maybe more like this, note it only uses 4 elements and two links.

 

enemy and visible are still a link as well as player and los, its just docked

 

Ugh...

I advise to check out Unreal's blueprints. As much as I dislike them, if you're thinking about any kind of visual system, you should definitely familiarize yourself with them first... and they're definitely more pleasant to look at.

Also, there are blender's nodes.

-------
Also, I'd still like to know how do you plan to express something like this:

Code (csharp):

1.  
2. setVisible(enemy, LOS(player, enemy));
3.  

In notation that doesn't use commas, semicolons or braces without temporary variables.

 

I'm still trying to understand why he has such a hate of , . and ; Also if your goal is simply just looking for a cleaner looking syntax you might want to look towards python for inspiration with its lack of braces for scope and its use of whitespace to define scope as well. But even python still uses () for functions and uses punctuation like : to define the start of a new scope like a if, loops, methods, classes and contexts.

Python has its collection comprehensions which are great, but C# can accomplish much of the same using Linq.

Also even if C# is a little more wordy and verbose than you would like, its not like it matters, since the IDE can assist you a lot in a static and strongly type language like C#.

Also all the exemples you have giving aren't issues of the language being used, but is things you could write your own functions and extension methods for.

 

I can sorta understand the logic - if the language has too many different separators, and they all need to be used often things would get annoying very fast. However, majority of text in C# is latin identifiers, and at okayish typing speed of 400 characters per minute, occasional comma or semicolon shouldn't bother you much. If I had to mix '`/:;[]{}()<> in one line a LOT then I would probably complain too.

Speaking of which... has anyone here used APL?

Code (csharp):

1.  
2. ⍎'⎕',∈N⍴⊂S←'←⎕←(3=T)∨M∧2=T←⊃+/(V⌽"⊂M),(V⊖"⊂M),(V,⌽V)⌽"(V,V ←1¯1)⊖"⊂M'
3.  

I've never had a chance to play with it, but I heard it had some interesting ideas (right to left evaluation). It also requires a special keyboard, if I remember correctly.

Another interesting approach was used in spectrum's BASIC. Spectrum had 64k ram, and most of it was already being used for something. So in order to save space, instead of typing every keyword as a text, they mapped every BASIC keyword to a character code within 128..255 range, and a keyword could be entered with one keypress.


Thinking about it, it is sorta the way some advanced calculators work.
-----

And thinking about it even more, IIRC, in common lisp (with its parenthesis hell) common approach was to let the editor match/insert parentheses instead of monitoring them manually. Meaning that AroowX's language woes could be probably solved by some sort of IDE plugin/coding aid.

 

Except you cannot tell at a glance what it's doing. Text-based code is meant to be easily readable as well as writable.

 

I'm not interested in the rest of this thread, but just wanted to point out that this isn't quite the case, a fact I found out recently.

It is in fact the language that causes this, as the language structure (using compound words) means that 'yellow snow' is one word, as is 'deep snow'. I found this on CGPGrey (great channel)

You can see a more detailed reasoning here: https://en.wikipedia.org/wiki/Eskimo_words_for_snow

So yes it's technically correct that they have many words for snow (many more than 17 actually), I would say personally that it doesn't quite count

Anyway, I just really like that little detail so thought I'd bring it up... Carry on!

 

Or we could go for a style more like this and a layout that might be easier to understand.



Personally just like synaptic clutter, I think we should avoid visual clutter.

Maybe what we need and is probably overdue is a configurable syntactical programming language, where the programmer can choose it's style.

 

What you're proposing with this is akin to the current state of Linux where you have hundreds of distributions. Allowing everyone to choose their own style won't make the language easier to use. It'll simply introduce another complexity for a beginner to learn. Wasn't ease of learning the whole point of this thread?

 

This is literally the exact same thing but sideways.

 

At a glance it is depicting a loop. LOS->visible->enemy->LOS
It also suggest that player is a part of LOS, and that "visible" can be removed from "enemy".

...which is why I told you to check out unreal's blueprints.

 

None of those visual representations mean anything to me intuitively. I only understand what's going on because I know what player, enemy and LOS generally do with eachother. If it was a more abstract concept I'm quite sure it would be pretty much unintelligible. For a visual system to be able to represent the myriad of contexts of different relationships between all the nodes that might make up the visual language, it would have to be so sophisticated as to be totally useless.

For example what does a noodle with an arrow mean anyway? It's a very ambiguous representation of many possible interactions. What if you wanted to represent a different sort of interaction, maybe you would use a green noodle for that. How does this help? At the end of the day, you have to ask yourself, what good is this, what are you trying to escape?

The problem is that there's only so much you can reduce information and still have it represent a useful concept. Like @Ryiah said, many of the ways that people tried to streamline language haven't really done anything - for example the first time I tried to script in Python it took me a while to figure out that my script wouldn't compile because some of the blank spaces I'd made at the front of the lines of code were made with the Tab key and others with the Spacebar. Tell me, isn't a damned semicolon just a better idea? The point is that the compiler still had to 'see' the structure in the language, I still had to define that structure, and all this 'streamlined' idea of python did was hide what I was doing from ME.

The only way forward in terms of reducing complexity, I maintain, is an intelligent system which not only converts information from layman's terms to code, but also can modify that code according to changes described by the user. That way the compiler can 'guess' a lot of what the user wants, and then if the user explicitly rejects some part of that 'guess', update it's guess and the code.

 

Which kind of sounds like what a modern IDE does with autocompletion (given an API with descriptive names), Macros, plus some automated learning (which very advanced IDEs might already employ, IDK).

I suspect if we ever go beyond that and into the direction you are talking about, the amount of time it will take users to "train the system" for whatever they are trying to achieve next is about the time it would take them to sort it out themselves.
Given you are not doing the same thing again, the next task will once again take some learning for the system.
And if you only do rince-and-repeat tasks, well, I would say if the system can beat good old copy-pasta, then only by a small margin.


Really, nowadays the problem seldom is the language. Its the users reluctance to learn a useful tool and instead go looking for a magical wand that does the work for them.
Its kind of a symptom of our time if you look at selfdriving cars and digital assistants. But while there certainly is value in reducing the workload with intelligent solutions, in most cases the saving in time and effort is quite minimal. And at least for programming, that intelligent solution is not there yet.

 

But that would end up something like this (example found online):

 

Because this is a realworld example, while yours is pure theorycrafting.

And blueprint tries to be everything to everyone, while your example tries to streamline the graph for one single inflexible purpose. If Blueprint was a visual node system for one single game genre, streamlined for the smallest possible nodesystem size, then it might look more similar to yours.


And no, I am no fan of Blueprint. Not at all. But I think you underestimate the complexity of a general purpose language, visual or code, a bit.

 

Not to derail the language wars, but LOLCODE is really the way to go here.

Code (CSharp):

1. HAI 1.2
2. CAN HAS STDIO?
3. I HAS A VAR
4. IM IN YR LOOP
5.    UP VAR!!1
6.    VISIBLE VAR
7.    IZ VAR BIGGER THAN 10? KTHX
8. IM OUTTA YR LOOP
9. KTHXBYE

 

I don't think opponents of UE4 fully understand the power of the Blueprint system when backed by C++. On a team, a programmer in C++ can expose Blueprintable functions to the rest of the team in real time. This whole graph you posted here could be a single node. Build the pieces in C++ and put them together in Blueprints. Use some basic inheritance to get things moving in blueprints, and then refactor out of blueprints into the base class where necessary.

Blueprints alone let you build some things very quickly instead of waiting for some programmer to complete their task...such as a door or button. Even as a programmer, many times it's worthwhile to piece together some logic in BP before moving the code over to C++.

The workflow between C++ and Blueprints also has the benefit of keeping your folder hierarchy much cleaner.

 

@Arowx what are you making the pics in? (just curious, don't recognise the software)

 

In my opinion, this example is cleaner than what you presented.

Blueprints have cleaner indication of what is going on, although compared to text form information density is still very low.

White line is execution order. Colored lines indicate argument type. Capsules are parameters. Boxes are functions.

 

Honest to God, I have no idea how people can say they've made a full game in it's entirety using just blueprints.

The noodles are just so confusing. Maybe it is because c++ is too unpalatable to work with.

 

I'm inclined to believe it's more about "Why did I make it in Blueprint? Why not!" than anything else.

 

I'm inclined to believe most would think a node setup easier than randomly picked c++ tutorial in unreal engine

https://docs.unrealengine.com/latest/INT/Programming/UnrealArchitecture/Actors/Spawning/index.html

 

To be fair C++ has a bit of a reputation for being difficult and Blueprint isn't intended to be used by actual programmers.

 

To be very clear, the whole point of what I described is for someone not to have to really be a programmer at all, to avoid altogether not only having to train as a programmer but also to avoid having to think like one when creating the software.

If someone is still going to interact with a programming language at the level of variables, loops, functions with arguments etc, they still have to communicate at that level, with syntax at that level. My idea has nothing to do with them. In fact you might say it has to do with going all out in the direction of obfuscation, but in a way that is practical for certain uses because the 'programmer' will have absolutely nothing to do with the code directly, even at the level of a scripting language.

See, this is the problem. The ways that languages try to make the user experience better, by 'simplifying things', requires the user to continue to operate at the level of the unsimplified code, to continue thinking at that level, because the construction of the code demands that they understand the low-level relationships going on. That's why, only when the user can totally avoid having to think about the low-level interactions of the code, and the compiler/whatever can be trusted to take care of code construction without breaking low-level syntactic rules and without any human supervision, does it make any sense to have a 'simplified' language.

In a way, it's like memory management in scripting languages. If I was writing code in C# for Unity and I had to think in any way whatsoever about memory management, it's very likely that it would be far better for me to operate in a very low-level language where I had to manually allocate and deallocate memory, and some sort of hybrid language where I only have to partially worry about memory management would be worse than all of them - because I'd still have to understand all of what was going on memory-wise in order to properly deal with the part of it that is manual, but at the same time a lot of what was going on would be hidden from me. But when I don't have to think about it at all, then it makes sense to hide it totally, and have the compiler deal with it without me really even having to understand it.

In regards to self driving cars, the principle is the same. If the person being transported by the car has to be ready, hands on the wheel and foot on the brake pedal, it's pretty useless in terms of benefit to them. But if they can lie down on the back seat and go to sleep, then it's a huge advantage (for example if it takes them 2 hours to get to work, and they only slept four hours).

The idea is that the benefit of intelligent systems only becomes a real benefit when it doesn't need redundancy in the form of a trained human operator. But after you cross the line, the benefit is huge.

 

@Billy4184 the main problem i am seeing with that idea, is that the hard and time consuming part of programming has nothing to do with the tools used to program. If some better way came about that was better for creating logic than programming languages it would be adopted, but the title of software engineer would remain even if the workflow changes. Since the hard part is not the programming itself.

What makes someone good at writing software is their good problem solving skills and ability to use and combine their various tools and things around them (API's, math, and logic) to MacGyver a solution to the problem at hand.

Even as the tools get more intuitive, their will still be a need for engineers, since we are practiced at solving logic and technical problems, just like a Artist is tuned at solving visual and design problems.

 

Well I don't disagree as such, just that the software engineer will be the computer itself. Of course, we're not there yet, I'm pretty much just trying to say that the only way I can see programming becoming significantly 'easier' or more streamlined that it is now, is when it isn't really programming any more but rather a set of orders, sort of like now you're the boss and the compiler is the programmer.

When that will happen, who knows, it's certainly not very close. But in the meantime I can't see a way to significantly simplify programming from what it is now, that's basically my point. When you operate at the level of code as it is right now, it doesn't really make much sense to hide parts of it or obfuscate it, you still need a certain information resolution and spectrum of syntactic meaning, and whether that's in the form of words or some noodle editor it doesn't really change anything. Only when you move totally beyond a certain level can you put the lid on it for good.

 

Unless you're one of those "Everything in one script" kind of programmers, it should be pretty obvious how it can be done.

 

Just to be clear when I say a full game in blueprints I mean while keeping sanity.

 

The problem with discussing node based tools is that many programmers and like-minded people are stuck in this dream world where they only see it as a tool for dummies based on their own way to look at the world.

Some people struggle with programming because their brain is MORE based on visual information. They don't have a problem with the concept of programming, they might even be a hidden genius. They just have a problems with reading all that text the same way a traditional programmer have problems with reading all those nodes.

Some people attempt to argue that the node charts get to big... well... do you write all your code in the same file? Give the node tool a way to combine nodes or brake the chart into smaller charts that accomplish specific tasks. The same way modern languages brake code into classes, functions, structs and so on...

Both nodes and text have their own benefits and drawbacks. They are two approaches that can produce the same code and compile to the same software. They should first of all be two different approaches to get the same work done depending on if your left or right brain half is dominant.
We can then discuss simplified text and node based tools for people that doesn't have a talent or interest in programming

ps. I have a problem with text-based programming but I don't have a problem with programming at all. These two shouldn't get mixed up with each other. Or to simplify this for programmers...

text != programming

 

I get the idea, but this idea is nothing new. In fact, it is the "perpetuum mobile" the IT Sector has been looking for for at least 15 years.

The (in-)famous code generator. And we all know the story: it never worked. Not to the extent where you could really put a domain expert in front of it and expect him to just hammer out a process without having to worry about technical details.
The result of that experiment where that the code generators that did survive the test of time are nowadays used by programmers to ease the most repetitive tasks in some areas.

That is at least the truth where I work... and I was even doing an evaluation for a code generator as an assignment for an external company during my studies. The result was a mixed bag. Yes of course you can do it... don't expect your average business analyst to be able to get useful code from it.


Of course, this is the past. As soon as computers get so intelligent that they can actually program themselves, it might actually work. At that point, a stupid decision by the domain expert using the code generator might no longer doom the project to failure because the code generator will recognize a problem, and will decide to overrule the users input.
Though at that point you could probably get rid of the user altogether...

Because you know what? Domain knowledge is just as easy or hard to develop an AI for than programing. If your computer is intelligent enough that he can replace a good programmer, he most probably will no longer need a game designer.
Artists will be the last to be replaced by this new all purpose AI game developer, but even they are not secure once the computer has developed what is sorely needed for a good coder just as well as for a game designer or an artist: creativity.

Of course this is science fiction for this exact reason: Coding is an extremly creative job, even though non-coders might not understand that.
It is easy to write a program that churns out bad code. Just as it easy today to write a program that churns out bad art.
Good code, code that is really cleverly written for a purpose, code that performs well needs a lot of creativity to pull it off. It needs a creative brain with a lot of indepth technical understanding, AND the needed domain expertise to pull it off.
Todays PC and even Supercomputers might not be enough to run a good general purpose code generator that REALLY churns out good code reliably.


Now, sure, there are tasks that are not mission critical, not that performance hungry or whatever. A less intelligent code generator might work there. But then, its basically what Unity does already.
All you need are more out-of-the-box solutions for glue code or systems (which today have to be gought from the asset store as packs or standalone solutions). Creating a stock script for every normal task a dev might need might be a better, more scalable solution than trying to come up with a complex code generator that in the end will not do more than generate simple code for simple tasks.
After all, if all you are doing is create a CoD Clone, you only need a good FPS Controller, an enemy AI Controller, some shooting mechanic script and something to keep track of levels. The amount of scripts for this kind of gameplay might actually be rather small.

And lets be honest, if the stock gameplay is not what you are looking for, your not-so-intelligent code generator will most probably churn out crap again because you are now trying to pull off code that goes outside of what the code generator, or Unity is optimized for, so you would need some creative coding to prevent the code from performing poorly.

 

I don't buy it. While someone might have slight visual bias, if they can read, write and talk, they can program.

Fully visual thinking to the point where it makes it impossible to write a script... I don't know, this kind of person would probably be only capable to communicate by launching fireworks and splashing differently-colored paint on people or something like that.

I still believe that visual programming is either a toy or a crutch, and there are very few edge cases where it is somewhat useful. Trying to it into some kind of superior tool... it is just a pipe dream.

 

First of all, I am obviously not speaking about 100% dominant visual processing. That is when you get diagnoses like development and / or autistic disorder etc... I am talking about visual dominance within the normal range. I'll edit the text and make it more clear in a moment.

Eh... no... just no... if reading, writing and talking automatically made it possible for everyone to learn programming then why are so many having problems with it? Programming is structured, logical work and not everyone is suited for it. If you are capable of doodling, are you then automatically suited for learning art? Can you learn to see shapes, colors, visual structure and so on...? I don't think so...

We can also discuss dyslectics, they can read, write and talk but they are horrible at working with text. They are an extreme but they can still be great programmers and authors if given the right tools because text processing skills doesn't make you into any of these two professions. It is only the tools that dictate that we have to work with text... but give a node based tool with all the bells and whistles and it becomes easier for him to develop code, give him a voice based input and output system and he might turn into the next Stephen King or John Carmack for all we know. Why limit the tools because we can't see outside of the box? Why stop using rocks for hammers? Bot can do the same work... right?

Superior tool? No, did I make it out to be that? It is a different tool for the same purpose. It got pros and cons the same way text editing got that... there is more ways to shape a sentence then with just text... I am using both tools and nodes are wonderful for prototyping and visualizes the whole system but I write it as optimized code when I nailed the details down because I don't have that granular control in the node editors....

 

I can buy this sentiment.

I live in a world it's the opposite. Everything is programmed in node based languages. And the idea of switching to a text based language would be horrify most people in my industry.

Of course, running major hazard chemical facility has different goals and requirements then making a game. I try very hard not to make pretty explosions. I do think text based programming is more suited to game making. But it certianly could be done.

 

The only programming language i'd like them to add would be c# 6

 

Yes, if they put enough hours in it. Closest real life thing to a programming is speech. Closest thing to making node diagram is building plumbing system for your house.

Actually, if you're capable of doodling, you ARE automatically suited for learning art. Talent gives very small advantage, and plenty of artist say that if you can draw a line, you can learn to draw properly. See loomis books, betty edwards, etc. Basically, if you put enough hours, you can get to the level of almost any artist you see.

Your brain is not a brick you know? It is flexible and capable of learning new things.

IMO, the reason why people struggle with programming is because of psychological problems. They either expect to become great in three days (and get disappointed) OR they assume that "it is difficult, I'll be never able to do it", and give up without trying. You're doing the same stunt with art, by the way - you assume that there is talent and you or some people don't have it, which magically prevents them from learning how to draw. Art can be highly logical, by the way, and has parallels with programming.

Keep in mind that working with engine like unity mostly requires scripting. It is a very low skill level, compared to say, making the whole engine. Nobody requires users to become pro developers, just making a basic solution most of the time will be enough. Pretty much everybody would be capable of doing that.

 

As an artist I fully agree. The only thing I'm not sure about is, if everyone is able to make the same amount of time investment into learning new skills. I have a suspicion that there's a hard limit for some and that this is what gets incorrectly blamed as "lack of talent". And if that's the case, I wonder if and how that limit can be changed. In time science might be able to tell us, but I think they haven't figured those things out completely yet.

 

If that were true, there would be a lot more mainstream visual programming tools. Businesses commit many billions of dollars to custom in-house development. Even small improvements have a huge fiscal impact, and they're (mostly) all searching for those incremental improvements. Visual (or node or diagrammatic or whatever) programming has never been a significant factor in the real world.

The closest I've seen in the real world are certain business rules engines. Tivoli has a pretty good visual editor -- but it requires significant prelimiary (typed-in) work to support it, such as wiring it up to databases and expressing those relationships and creating (typing) business-friendly descriptions for all that stuff. And in the end, all that visually-edited stuff that the supporting business teams generate is actually converted to plain old text (and in the case of certain engines like IBM's ODM, it ultimately ends up as C# or Java).

Additionally, for any real-world modern programming language there are likely just too many complex interactions to make simple visual representation a reasonable expectation. Fire up PhotoShop and paint me a picture of how you'd visually express something like this composition function from my serialization utility layer:

Code (csharp):

1. public static void ComposeForClient<T, U>(T dataDefObject, U composeWithObject)
2.     where T : class
3.     where U : class
4. {
5.     IClientCompose comp = dataDefObject as IClientCompose;
6.     if (comp != null) comp.Client_Compose<U>(composeWithObject);
7. }

 

We are now talking about how to support people to learn to drive faster instead of trying to develop a selfdriving car that does NOT crash and burn as soon as it runs into a situation it hasn't been designed to handle.

This I can support wholehandedly. Yes, learning to program is hard. To hard? I don't know. But it certainly seems above the threshold many today can handle, which, given EVERYONE will be a programmer of some sorts in the future (either you program your cooking machines, you program your assembly line, you program the robots that build the house you are tasked to, or whatever else), is obviously a problem. I don't think that todays kids, or maybe their kids will be vastly more suited to learning programming than adults today. I might be wrong here, but I will not hold my breath until that generation of programming naturals is born.


Will visual node systems play a part in this? Maybe. Maybe not. I cannot believe either that the visual nature of these systems is solving the problem for most people not able to grok programming today. There might be a minority that would get it, but are just too text-averse, true.
For most, its the amount of technical knowhow you need to have, besides the domain expertise. And again, on its own, the visual scripting system does nothing really to change this.

 

I'll go back to my imaginary day job then.

Never is a very strong word, visual languages are definitely significant within the niches were they make sense. They are standard for machine control.

In fact come to think of it this next one is not really true either. I've just built and deployed a SQL database without writing a line of code anywhere. Complete with a decent looking front end. I built the whole thing using drag and drop without writing a single line of code.

Sure code generation is not to the point where I can tell the computer 'Make a database to record some stuff for me' and have it work. But I can make a database without writing a line of code. And a couple of decades ago that would have required a skilled programmer.