As Unity is very .Net based could it adopt the F# and Visual Basic Languages?

I have still yet to see a compelling argument as to why Unity should adopt a new language.

 

What's so bad about redundancy? In most of my work I deliberately try to communicate in multiple ways simultaneously. I see nothing wrong with having both explicit and stylistic communication. And having the explicit tokens there allows us flexibility in our style, which would otherwise need to be rigid.

Also, you're saying that they're "not content" because white space gives the same information, but in the languages relevant to us as Unity developers, past one space to separate tokens white space is explicitly not content. As in, the compiler actively ignores it per the language specification.

The actual solution is what I'm interested in exploring. I agreed with you from the start that this stuff can be improved.

As @Ryiah pointed out, among experienced users I don't see why this is a complaint in programming and not in written English. Just like in programming, both the punctuation and the white space are important usability elements. I can't help but notice that your posts here are well formed in both punctuation and white space. Why?

(For inexperienced users this stuff seems terrible because the compiler gets grumpy and points out every single mistake you make.)

 

Python is suited to more jobs, but would make a worse job of expressing a game's needs. There are not many games using Python in any capacity. Python serves every field that does not require any specialisation - indeed it's great for general programming.

But game development isn't general programming.

 

I loved the idea of SkookumScript back when I was working with UE4. A programming language with features specifically for gameplay. For example

Code (CSharp):

1. // Guy and car both start at same time.
2. // Next line is run after whichever completes first
3. // and any remaining commands are cancelled.
4. race
5.   [
6.   guy._walk
7.   car._drive
8.   _wait(120)
9.   ]
10. println("Completed")

Actually kind of suprised they are not on Unity yet considering I know they raised some money from VC's.

http://skookumscript.com/about/

 

Lets not forget that we used to have Boo, which was pretty python like. If nobody used boo two years ago, I don't see why it should be any different now.

 

In this case it's distraction, so redundancy aggravate the case. Trailing bracket are even worse when they are nested one after the other, you can't even tell which one is closing what anyway.

Depend on how experience you are on programming, it's one of the more recurrent complaints of new users. I still prototype on blitz3D because I don't have to think too much about the language (despite it being way more limited), and it allows me to do that. Then I switch to unity.

But then the thing it's not limited to typical language, shader node are an example of alternative. the addition in unity is the equivalent of them adopting a new language, here a visual language.

Written english is resilient to noise, having a typo don't break the logic of the game. Looking for an error because a missing ; or bracket, because you had to move around some logic or just mispressed two keys. Especially when the code compile without error, can be damning to look for. I have spent multiple weeks banging my head due to such typo. I mean 20 years should be enough to be experienced right?

Also that's an unfair argument, because remember the lithium forums? How people complained at the presentation of the forums? A lot of presentation decision are made for you already, where the avatar name are, the default fonts, its size, color, style, where the title are, where the footer is, the name of the thread, how quote are made, etc ... You take them for granted, it's an actual craft. I only wish code was as well made in presentation. ANd then you can actually choose what to highlight with a panel of tools, while it doesn't change the meaning, allow to change emphasis, what if we could change emphasis of code?

The thing is as a designer, the logic is constantly evolving, I need to make vast change on a whim, so lessening errors allows to focus on the right problem instead of chasing stupid characters (among other problem).

I was recently blocked on a convex shape code for that, and before that I had to struggle with a planetary tiling, I got stuck week on something that was a typo, obfuscated by the style, up until I adopted the pythonic style with hidden bracket. And the error resulted in behavior that looks like logic problem rather than typo, lots of hair was pulled.

I mean whitespace specifically and all isn't the problem really, that's the thing you get hung up on, the problem (as I see it) is also broader than what's discussed here, but I stuck to the narrow idea of presentation because that's the direction it was going on.

But to put perspective on that idea, its' a continuation of idea like "type", "object", "private" vs "public", etc ... those are thing to prevent the programmer to make direct unnecessary mistake, we don't really need to make a distinction of public and private, your code will work just fine. But Language designer realize that enforcing them would allow less mistake and more sharing (or like python you recognize that people are adult, allow to invoke private member, but with a strong side eyes so they know it's wrong and you shoudl know what you are doing). Assembly don't have those concepts, it's only the compiler that warn you to enforce best practice. Instead of having teh compiler warn you for menial thing like "syntax typo", we can push this up to the IDE, which already do in some way.

Truth is that the idea that's it's fine can be a survivor bias, you got through without the hassle, other gave up way early, not because of the logic (they can do it with visual node most of the time), but because it's a mess to them. I do burn out on code (unlike drawing where I zone out), I guess you can reach a state where you are in the zone, hence why it doesn't feel important. Right Now I spend more time on the forum, because I burn out coding a relief shader and even simple math don't want to go through the skulls, that's a massive let down.

I need this disclaimer, because a true solution should be holistic and take into account all other aspects. So since it's just a discussion and I can't implement it right now, it's best to limit the scope of the solution. Like you said it don't work for custom type, does that break the entire concept or it can be compatible for a specific solution for custom type? In visual language I think struct and class has different node shape as an alternative.

That's right, game tend to have two phases, the design and (efficient) implementation, it's advised to toss all your prototype code of the design phases and let a true programmer do the real works once your design is frozen. We need something for the design phase, for designer. Also most studio have a script language, like lua, on top of real™ programming for that purpose, they end up recoding critical part into real language™ anyway, but at least teh designer didn't stall waiting for the programmer to implement a task they will toss 15mn of playtesting later.

If only people made tutorial for it, when I started there was zero boo code but c# I could start using zillion of non unity c#. Also boo is rarely connected to python (so I wouldn't know to look there) so it look like that weird thing on the side I had no idea what to do with. Also javascript allow a lot of we dev to cross other, then get accustomed to the complexity and finally crossed other c# which syntax is very close.

Anyway, that's a great discussion, and I thanks anyone who participate in good faith, it allows me to deepen the subject, maybe one day I'll be in position to propose something, who know.

 

Some of it is chicken and egg. Tutorials don't get made because there is no demand. There is no demand because there are no tutorials.

On the other hand that does point to one of the central issues with languages for Unity. Community support and resources are the most important consideration. Most of Unity's market doesn't care about special features. They don't care about specific programming paradigms. They care that they can google a specific problem and find a specific answer. They care that they can ask a question online, and get an answer.

Ultimately most of the market don't care what language they use within Unity, as long as its the same language everyone else is using. Which is going to make introducing any new language difficult to impossible.

 

In this specific case I'm not advocating for new language, just an IDE layer to remove verbose syntax, + some improved IDE sugar.

 

I can't tell if you're saying that (for instance) public and private are unnecessary, or that public and private are a tool that helps people cut down on unnecessary mistakes.

 

But the preferred language did change. I'm partly to blame. Unityscript was the main language way back. Official examples were written in it and the "new" Unity Answers had all Q's and A's in unityscript. You rarely saw C#. It was less popular than Boo.

Gradually, slowly, more people started answering Q's in C#. I never learned all of UnityScript, but faked it. Then I started writing answers in C# with "sorry that this is C#" in front. Because everyone used unityscript. Nothing special happened -- C# just gradually became more popular.

 

I'm saying that a lot of programming convention is already the latter, the former only enforce discipline on the programmer, not the compile code.

https://mail.python.org/pipermail/tutor/2003-October/025932.html
Private vs public is a culture things, it's the taboo, not a fundamental programming thing, just like banning goto in favor of loops, it's a culture about efficiency, but fundamentally mean nothing to the logic.

I feel like it's because of the influx of more traditional programmer over artist, as unity started to become "professional" and not something panned as a toy for artist because graphical interface.

 

Python barely exists in game development except for toolchain, it's worthless trying to bring up charts of most popular language because C++ and C# dominate that end to end. Nothing comes close. Maybe some Java for web, android games etc. No Python was asked for in all the job listings I checked.

An argument for a family car being nippy and useful for nearly all road tasks isn't exactly going to be useful when I'm trying to do some heavy construction or trying to win a race.

Why though, if Python is so great? I think we find it can't all be explained as legacy C, C++. I think it's more the fact that C++ compilers are hot stuff, and the body of work is all in C++ and you can do things in C++ you just can't achieve in Python.

That achieving thing is pretty important I guess, more than the syntax. If I had to guess, syntax has no real bearing on work being done.

 

There are two game scripting languages: Lua, and Everything Else(TM)

A bit more background on that for those who weren't using Unity back then:

• C/C++/Objective-C programmers coming to the Engine started using C# since it was more familiar (I know that's why I did).
• Unity absorbed a lot of former XNA devs before MonoGame became a thing. Especially when MS dropped XNA development. This is probably what accelerated C# usage initially, since it was already there and they didn't have to learn a whole new language at least.
  
• A statically typed language like C# maps to the problem space of high performance game development better than a dynamically typed ECMAScript language does.
  
• Large bevy of existing C# stack overflow answers, bitbucket/github repos, and .NET dlls, often free and compatible enough with Unity after a bit of modification.
• Performance issues with UnityScript compile times.
• Performance issues with UnityScript itself, C# could simply do certain things faster and wasn't slower in any area as far as I can recall. Generics especially.
• UnityScript really couldn't interop well, especially when there was less API surface covering iPhone, Android, and Consoles.
• UnityScript basically required Boo to do some of it's syntax manipulation and other things (I think this was how

  #pragma strict

  mode worked?), and there was a distinct lack of Boo users outside the initial champions. Boo never caught out much outside of Unity and a handful of Unity developers. This increased the cost of maintenance for UnityScript.
• UnityScript was confusing because it was JavaScript/ECMAScript EXCEPT IT'S NOT REALLY HAHAHA.
• The need to do special compiler passes for C# and UnityScript and Boo was literally slowing down large projects that had mixed languages due to programmers using C# and artists using UnityScript.
• Most of the better early Asset store frameworks and editor tools provided C# as the API, as it became a pain to support multiple languages.
  
• Due to the above, most professional dev houses just chose C# as the studio standard language and forced their artists/tech artists to learn enough C# to get by. I know at least in two companies I worked with did this, and I did it for my own projects and contract work early on.
• As C# is the "core" language of the .NET framework, it's really really well documented how your code can transform to IL, and this ties into testing and refining stuff like AOT/IL2CPP/Burst, since they transform IL in other ways.

Here's where I see the future going:

• Engine developers in general are realizing the benefits of having a standardized language (you get more programmers onboarded quickly, you don't have to maintain the standard spec at all, you only have to pay the cost of interfacing with a fairly well documented framework instead of something made based only on the engine developers original needs, etc). Unreal no longer has Unreal Script for a reason.
• Artists gravitate towards Visual Scripting no matter how much you want them to do otherwise. Unreal and CryEngine are moving in the direction of Having the C++ world for programmers and the Visual Scripting for artists. I don't doubt we might see something on Visual Scripting in Unity next year since it's supposedly artist/UX focused.
• With things like Burst and High Performance C#, I forsee Unity moving/rewriting more C++ engine code to C#, and eventually the engine itself will be mostly C# with a thin layer of C/C++ to deal with 3rd-party libraries and platform features. This also means more, if not most, of the source code could theoretically be exposed over time, since there'd be no point keeping it in native if performance was the main reason.

 

It's not the the argument I'm answering with that graph. At all. Check what I was answering to

I still think that the visual scripting paradigm solve the wrong problem. It's the kill bill's superman syndrom, programer think they are super man, so they disguise (aka visual scripting) as clark kent to appease the artist. But human aren't as awkward than clark kent.

But in order to proceed in the discussion, you would have to understand the real problem and not the symptom like:
- visual scripting
- removing bracket
- new IDE presentation
- unityscript, python
- Excell programming
They all point to a problem that is the management of the code itself, not the logic, the busy works around everything that distract from creating model fluidly. In visual syntax you can't make syntax error, only logic error, it's self documented and can show data flow in a single view. These aren't proper to visual node language either.

The real problem is manipulation and presentation of the code. Not mere language concern.

 

Mechanim. The original script-based animation system was just fabulous and so easy to code. But I think very few people knew both code and animation basics -- I think I was the only volunteer answering Q's on it over on UnityAnswers. I miss it, but switching to visual Mechanim was probably a good move.

I've never used Unreal, but I knew people who did, 10-ish years ago. I feel like I remember drag-and-drop shader coding, and a Scratch-like language (drag and drop coding for children) for general coding. I think it's long been well-known that going from visual coding to any sort of typed-out language is a big hurdle.

 

One of the more recent optimization talks they gave suggested that the old animation system is still very much considered valid by Unity. I seem to recall we had a small discussion (read: rant) about how they kept changing their policy on whether you should just stick to Mechanim or use both systems.

 

Ah -- I completely forgot that about strict. iOS is another reason unityscript lost traction.

When Unity started it was pretty much for PC (or some console? Not sure). Cell phones and tablets weren't really a market yet. For a PC build, you could use unityscript as is, including shortcuts (from memory) like not declaring variables, transform.position.x+=1, and floats not needing an "f" suffix.

When iOS became the hot market, it turned out you needed #pragma strict. That cut out some shortcuts, making it not all that much nicer than C#.

 

On this point, unless they get Garbage Collection well and truly solved I don't imagine the core engine coming to managed land. That said, with the work they're doing all over the code toolchain I wouldn't be too surprised if they did manage to solve that eventually.

Otherwise, yes, I agree. The more traction Unity gained the more developers with prior experience it got, which ended up skewing the user base drastically towards C#, probably for reasons that didn't reflect on the languages themselves. Having multiple languages in use meant heavy overheads, so things are steadily consolidating towards just C#.

 

Yeah. Once you threw #pragma strict in UnityScript became C# with poorer documentation.

 

Almost wrote a none linq code today, stupid me! Orignal code

Code (CSharp):

1.     public static class ActionExtensions
2.     {
3.         //TODO: reset this when bindings update Issue #179
4.         private static readonly Dictionary<SteamVR_Action_In, Dictionary<SteamVR_ActionSet, bool>> conflicts = new Dictionary<SteamVR_Action_In, Dictionary<SteamVR_ActionSet, bool>>();
5.  
6.  
7.         public static bool Conflicts(this SteamVR_Action_In action, SteamVR_ActionSet set, SteamVR_Input_Sources source)
8.         {
9.             if(!conflicts.ContainsKey(action)) conflicts[action]  = new Dictionary<SteamVR_ActionSet, bool>();
10.             var c = conflicts[action];
11.             if (!c.ContainsKey(set))
12.             {
13.                 c[set] = false;
14.  
15.                 foreach (var suspect in set.nonVisualInActions)
16.                 {
17.                     if (suspect.GetDeviceComponentName(source) == action.GetDeviceComponentName(source))
18.                     {
19.                         c[set] = true;
20.                         break;
21.                     }
22.                 }
23.             }
24.  
25.             return c[set];
26.         }
27.     }

Correct code

Code (CSharp):

1.    
2.         public static bool Conflicts(this SteamVR_Action_In action, SteamVR_ActionSet set, SteamVR_Input_Sources source)
3.         {
4.             if(!conflicts.ContainsKey(action)) conflicts[action]  = new Dictionary<SteamVR_ActionSet, bool>();
5.             var c = conflicts[action];
6.             if (!c.ContainsKey(set))
7.                 c[set] = set.nonVisualInActions.Any(other => other.GetDeviceComponentName(source) == action.GetDeviceComponentName(source));
8.          
9.             return c[set];
10.         }
11.  

 

...Good for you?

 

I did get an erection yes

 

The top one is more explicit and thus easier to understand at first glance for someone who did not write the code.

 

No thats a false statement. The second one is much more clear. It hides all the redundant stuff and focus on the domain

 

This is what OOP fanboys (and girls of course) won't understand. It is NOT a good thing. Every time I see something like that, I have to jump across the galaxy and check WTF is happening in the hidden code, because whoever wrote it, there is a high chance that (s)he was wrong.

And I didn't even mention the optimization this kind of code.

Maybe for you, it's clear and it's working, but it is not universal. I like the first code better.

Hiding complexity and hiding non-performant code in an application which should be very performant is bad.

 

I love magic one liners in my own code but when I take over a project from someone else I want to kill them for it

 

Well, ask any senior lead dev / architect and he will agree with me. Same with comments, all seniors agree with me they are a waste of space in most cases. Its just something you learn with time and experience.

edit: So you dont use any of the .NET built in methods then? Since they hide stuff?

 

I am a Senior Software Engineer at one of the world's biggest IT company. Any more questions?

When you develop a Java application which is running somehow, who cares in how many milliseconds, sure. Hide all the stuff. When you're developing a game which has a budget for the frame, it's a very bad practice to hide complexity.
Hidden complexity is something most people don't calculate with. It's bad.

 

Only bad programmers, a good programmer always look at how a method is written that he is going to use, and if its a external method you check the docs for its complexity. msdn always writes complexity for none IEnumerable stuff at least



If you dont hide any complexity you will have one mess of a code with the same logic over and over again. If you find a bug in that logic you need to go over all 100 places were you have cut and pasted that logic.

edit: Also hiding complexity is abstraction, and if you dont abstract again, one mess of a code

 

Well, of course we will start to talk in extremes... whatever. Good for you.

 

For enterprise development of web applications, I can understand trying to hide some of the complexity. But for game development where every frame has a tight budget, I strongly prefer longer, more explicit code that is not trying to hide information from me.

Also, Microsoft has repeatedly burned me on things where they told me I could trust them about various hidden complexity over the years. Anytime I even consider using Microsoft code, I set up serious test cases first to make sure everything is as expected. And in many cases, I have found that Microsoft's fancy solutions don't quite work as expected.

If it is code that gets re-used a lot throughout a project, I can factor my code into a class instead of re-pasting it 100 times.

 

And you guys happily use the slowest CLR there is in existance (mono)

Haha, the irony. Hiding complexity doesn't mean bad performance our domain allocates zero bytes per frame and is super optimized. For user actions and stuff that can only occour o(1) per frame and not every frame we do use some Linq and other nice stuff to increase reability of code

 

Well, as I said, do not assume anything until you looked into it. You're wrong, but well, whatever.

I still think using Linq anywhere even near Unity is bad. But it's your application and your choice, I respectfully disagree with you on this thing. I like defensive programming more than short programming. I have an IDE which is basically typing for me and highlights all the stuff used to crowded my mind (we came a long way since C64 Assembly). It's not an issue. But good for you.

 

Just test the integer peformance itterate over a collection it's 10 times faster on the .NET CLR, but it's a side note. Its actually there for even more important witj peromant code because the subpar CLR.

But again my code is super performant, probably more than yours but who knows and still maintainable because I keep a tight loop were peformance is needed. But it's ok, most Devs don't understand this.

 

You have repeatedly boasted about how great your code is and how performant your code is. However, you are assuming you are talking to newbies. While there are some newbies in this forum, there are also plenty of us with lots of programming experience. Don't assume your code performs better than mine, because it most likely does not. I have been obsessing about code performance for decades.

 

Likewise! Writing ugly code can not be exused because of performance

 

I won't enter in a whose 'tool' is bigger contest. I don't really care that much and it's silly.

Ugly is subjective term. What's ugly for you is not ugly for other people.

 

I not trying to be an asshole, just want to make you guys better devs thats all. I see so much ugly code every day. I'm just doing my part to make the world a better place (for devs)

edit: Maintainable code isnt that subjective actually. It just to look at history and see what have worked well

edit2: Take this library I did, it can serve web scale (Facebook scale) needs but still being very elegant https://andersmalmgren.com/2014/05/27/client-server-event-aggregation-with-signalr/

 

I think is worth stopping arguing and leaving it.

Is like talking about fashion.
That something works for one, not necessary works for other.
Just, like many says to avoid linq, while others like it for quick typing, if they don't know how for example, how to write relevant function.
blah blah
Very subjective and off topic.

No one will ever know, if his code is better than others, without benchmarking both sides.
So such assumptions are plain wrong and inappropriate.

 

VisualBasic? yuck disgusting.. dim = aka for dim people, openly mocking people using it.
Python = white space stupidity, it's like english with no grammer and large codebases with it are just dumb.
Lua = eugh

I could go on...

Lets just have Unity stick with C# and keep upto date with features from that now, all these other naff languages and homebrew scripting version are better suited elsewhere in the fields where other people have sadly latched onto such awful shoddy language designs.

 

You must haven't use them in right applications.
Sure VB has ugly DIM.

But python is actually quite good, as is designed.
Funny saying that

https://unity3d.com/machine-learning

Lua is superb and easy to learn. Also is good for sand boxing the code, specially when considering making game moddable.

Zero-k RTS was written in lua, and is active for over decade now.
https://zero-k.info/

Spoiler

 

I am definitely not a fan of ugly code, either. But I am flexible about code length as long as the code performs well and is easy to understand. I am always very happy to implement something myself from scratch if I see an opportunity to improve performance.

 

I used Lua in one of my open source tools called FreePIE. Nightmare, it overwrote protected memory in CLR land which completely corrupted the program. Maybe it was the .NET implementation, but really crappy. Ported to iron python in a day or two thanks to great abstraction

https://github.com/andersMalmgren/freepie

 

You mean you almost wrote code that would have had an actual chance at working with the new Burst compiler? Stupid indeed!

 

That code can max run o(1) for the entire session, burst and ECS is for alot of simple things. The core domain doesn't benefit from that

 

Have you actually done any benchmarks or is this just an assumption

 

If you have lots and lots of components with update methods that fire each frame you should consider moving to ECS. Or atleast those components that behave like that.

 

BEEP BOOP BOOP BEEP PROCESSING

 

No, I have tried ECS, evaluated it for our upcoming ballistics simulation. I'm an master of science engineer. We dont guess, ever

edit: Childish behavior btw

 

Claiming to be the best and schooling veteran on their jobs, is childish too (jokes on me I did that too)