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

Childish? That's a time honored forum tradition you are talking about there!

 

This reminds me of an old programming joke that goes something like "Oh sure, your way is much better. All mine has going for it is being finished and working."

 

It sounds like a joke old programmers make because their work is often neither finished nor fully working anyway, it just "behaves as expected."

 

I’ve enjoyed reading this thread and see you all talk about code like .Release that I’ve never seen before, and otherwise probably would never have known about.

My two cents m, we use Visual Basic at work and I hate it, just please no mmkay.

 

VBA's tight integration with Office is nice. But otherwise I won't go near the language. Python does a better job as a language for "non programmers". C# does better for programmers.

 

Yeah, office, excel in particular for all the reporting and automation with outlook (text messaging services etc)

 

In truth though many programmers and more so Unity programmers hit a wall with their bad design. They add new features and systems without any thought to maintainability, they force their new round system into the square hole in the domain. Sooner or later you will hit a wall and you will get into trouble. For example when Unity change something in a new version or a third party SDK change something. For example Valve rewrote their SteamVR SDK input system from scratch. You cant reuse anything from the old SDK in your project.

 

Talking about abstraction and maintainability, not even some of the bigger names in the industry can get it right, for example z-wave is just a mess of a protocol. Wrote this article about it

https://andersmalmgren.com/2018/10/20/z-wave-a-system-architects-view/

 

You really look shallow on the matter, repeatedly. Bring this so many times, for not know why?
Is that even relevant here?
You completely ignore the fact, that there is many many hobbits self learners and beginners etc., which due to lack of experience they design, as they learned, weather is right, or wrong.

Either way, there will be as well many good designs, as bad designs.
Why just looking at one side of the coin?

So locked on the abstraction ...
It is not required for every application.
Full stop.

 

Not required but if you want to scale beyond any kind of complexity other than Pong it is

 

But it doesn't matter, programming wall looks tiny when your problem is all mathematical, the best practice in math is increase the esoterism not only in notation, but also in example, advice, answers and learning.

 

Wow a 12 year old at a business related forum

 

Probably, considering @Murgilod selfie avatar

But where is written, that this is business related forum?

 

In a way is Unity making a new language based on Data Driven Development and ECS that they are adding onto the features available in C#.

Will Unity C# evolve into a different language or expand the C# language to fit this new paradigm.

 

Probably neither of these.

Unity's aiming to stay as close to the C# paradigm as possible without huge confusion on usage (see the debate around the execute functions syntax: they want to keep as much code as possible to mean the same thing roughly whether or not used in ECS/Jobs or in plain C# in a business application).
Also Unity's "additions" are highly performance-based and for solely game development. Regular C# does not need these at all.

It doesn't really make any sense to expand the C# domain to include these very specific use-cases (usually tightly dependent on one compiler -> burst) and also I don't see any attempt or path to Unity changing their scripting to deviate too much from the base of C#. On the contrary.

 

I'm giving you all the respect your comments deserve.

 

ECS like code has been used for years in corporate business, for example in BI solutions. When crunching extreme data sets

 

What programming languages are the favourites for ECS systems?

 

On backend I have worked with C# almost exclusively since 2001 so I'm a bit biased to it C# is very efficient in a tight loop for a managed language, when using arrays and structs there are strong guaranties, plus the JIT can do platform specific optimization which is nice.

 

I agree regarding C#. It is pretty fantastic for most use cases. The only time I use something else is when developing an embedded solution. I'll still use old C for coding $1 tiny microcontrollers with very limited memory resources. I'll use C# for nearly everything else, including backend and frontend.

 

I like what oxidemod or now umod have done with allowing modders to use c#, and have runtime compilation, so instead of some janky lua crap or what other junk scripting language homebrew, python etc, modders can use c# with all the benefits, and those scripts get compiled on any changes made to the files, while the game/server is running... pretty great really and a nice way to iterate on things using a language that doesn't look like it was designed by morons.

 

Obviously you haven't been working much with lua, or python, to understand their advantages.
And what implications brings C# runtime compilation, for online based games.
But according solution will work for some, but no others.

 

heh I'd say those languages are better suited to those who haven't had to work with them long enough to see all the terrible disadvantages

 

If DOD is ECS-like then yes. But that's called DOD. This ECS implementation is massively Unity-related. You don't really benefit too much from it if you don't use Unity and burst and Unity's job system.

 

You don't say, Unitys ECS implementation is Unity specific? I know there is a Nick cage meme that goes well here

But yeah, I have used the same paradigm alot in performance critical code. And the .NET CLR performes very well.

 

Honestly, you lost me, I don't understand your argument anymore. I don't know what you're referring to. Well, whatever.

 

It goes without saying that Unitys ECS is Unity specific any implementation that uses structs for the data and let them flow through some kind of controller will benefit greatly though, very much so on the .NET CLR. Cache lines and cache coherence

 

I refactored some Linq haters code today at work.

Here is my rewritten code

Code (CSharp):

1.         private void UpdateBatchButtonStateAndPrerequisite()
2.         {
3.             var prerequisiteReached = true;
4.  
5.             foreach(var group in ProgressSteps.GroupBy(step => step.Item.ParallelGroup))
6.             {
7.                 foreach (var step in group)
8.                 {
9.                     if (step.BatchButton != null)
10.                     {
11.                         step.BatchButton.Enabled = prerequisiteReached && !step.Running && !step.Started;
12.                         var text = (step.BatchButton as IButtonControl);
13.                         if (text != null)
14.                             text.Text = step.Item.Caption;
15.                     }
16.                 }
17.  
18.                 prerequisiteReached &= group.All(step => step.Completed);
19.             }
20.         }

Here is the same code before my refacrtor without linq doing the same thing

Code (CSharp):

1.  private void UpdateBatchButtonStateAndPrerequisite2()
2.         {
3.             var prerequisiteReached = true;
4.  
5.             var lastProgressStepGroupId = 0;
6.             var allGroupStepsUnlocked = false;
7.  
8.             foreach (var step in ProgressSteps)
9.             {
10.                 var isFirstProgressStepInGroup = false;
11.                 var currentProgressStepGroupId = step.Item.ParallelGroup;
12.  
13.                 if (IsProgressStepParallel(currentProgressStepGroupId))
14.                 {
15.                     // Parallel ProgressStep
16.                     if (currentProgressStepGroupId != lastProgressStepGroupId)
17.                     {
18.                         isFirstProgressStepInGroup = true;
19.                         allGroupStepsUnlocked = prerequisiteReached;
20.                     }
21.                 }
22.                 else
23.                 {
24.                     // Serial ProgressStep
25.                     allGroupStepsUnlocked = false;
26.                 }
27.  
28.                 if (step.BatchButton != null)
29.                 {
30.                     step.BatchButton.Enabled = ShouldButtonBeEnabled(prerequisiteReached, allGroupStepsUnlocked, step);
31.                     var text = (step.BatchButton as IButtonControl);
32.                     if (text != null)
33.                         text.Text = step.Item.Caption;
34.                 }
35.                 prerequisiteReached &= step.Completed;
36.  
37.                 if (currentProgressStepGroupId > 0 && (isFirstProgressStepInGroup || currentProgressStepGroupId == lastProgressStepGroupId))
38.                 {
39.                     prerequisiteReached &= step.Completed;
40.                     lastProgressStepGroupId = currentProgressStepGroupId;
41.                 }
42.                 else
43.                 {
44.                     allGroupStepsUnlocked = false;
45.                 }
46.  
47.             }
48.         }
49.  
50.         private static bool IsProgressStepParallel(int currentProgressStepGroupId)
51.         {
52.             return currentProgressStepGroupId > 0;
53.         }
54.  
55.         private bool ShouldButtonBeEnabled(bool prerequisiteReached, bool allGroupStepsUnlocked, ProgressStep step)
56.         {
57.             return !step.Running && (prerequisiteReached || allGroupStepsUnlocked) && !step.Started;
58.         }

 

I downloaded Visual Studio for Mac the other day and noticed the F# mention. Maybe I vaguely remembered this thread, but F# just popped out. We upgrade from Unity 3.0, 4.0 ... . I can totally see how someone, maybe not even knowing anything about coding, would assume that Visual Studio want us to upgrade from C# to F#.

 

Cool. Don't forget to refill the tissue-box.

 

I don't really know or use Linq that much, which of those two code pieces runs faster though?

 

I don't like either of snippets to be honest.

 

The complexity is like o(12) at most so it's irrelevant

 

The first one reminds me of older programs where space was vital. It's an "in place" algorithm, meaning it doesn't need to make a copy of the input list. Back then, using less memory was the main way to make programs run faster. All code was pressing up against memory limits, forcing swaps to disk and so on. Functions using less space meant less memory juggling, meant much faster. For fun, look up "Eight Megs and Constantly Swaping", which is the joke acronym for EMACS. It gives a feel for that long-ago time.

The thing I can't get over is "var allUnlocked = false;". Is bool now considered a confusing variable type?

 

The new trend is to hide the types, "because it overloads the developer's brain with clutter" they say...

Hipster gimmick.

 

While I prefer too nice clean meaningful data types, so is easy to scan with eyes, I suggest not going into that discussion

 

I'd say it does exactly opposite. Makes stuff harder to read, since I always try to find out what the variable type is. Seeing var for KvP makes sense, whereas bool as var is always an unusual way of saying "I don't give a F*** about this code".

No holy var intended.

 

Nice.

 

I see some sparks in background already. But nice play of words

 

How is var prerequisiteReached = true; hiding the type?

var someObject = GetSomeObject();

That might be hiding the type, I support both of above

 

I hate var. Var makes code harder to read (and debug/tweak), because it hides information. If you hate looking at code so much, just wear a blindfold. I'll never use var.

 

No one forces you to write maintainable code, its a free world

 

Noob question, what's the rational makes var more maintainable?

 

Comments, reduntant type declaration etc is noise and takes focus away from the domain. Though there are far greater subjects than var to be or not to be.

But all little things add up

 

I am against using var unless it’s absolutely necessary (accessing some properties).

Using var makes code unreliable in cases where you are using custom variables (think scriptableobject).

For example:

Code (CSharp):

1. Var myObjectType = false

While we know typically this would be a bool, you’re SOL if you’re supposed to be referencing something that’s a custom variable.

 

What do you mean by custom variable?

Only time you really need to not write var in this case if yuo are using a implicit conversion. Because the compiler would't know which type you want and it would just be a bool.

Code (CSharp):

1. public class FooBar
2. {
3.     private readonly bool enabled;
4.  
5.     private FooBar(bool enabled)
6.     {
7.         this.enabled = enabled;
8.     }
9.  
10.     public static implicit operator FooBar(bool enabled)
11.     {
12.         return new FooBar(enabled);
13.     }
14. }
15.  
16. FooBar bar = false;

edit: I can probably count on one or maybe two hands how many times I have written impicit conversions for my types. And a implicit conversion from bool seldom make sense

 

Custom as in

Code (CSharp):

1. Myboolvar = false
2.  
3. // as opposed to
4.  
5. Var myboolvar = false

Can lead to confusion

(Apology for formatting I’m on phone)

 

The only time var seems practical to me is if I'm using something that defines its own types and those types end up being something like WelcomeToTheJungle.WeveGotFunAndGames.WeveGotEverythingYouWantHoney.WeKnowTheNames because ultimately that IS just going to lead to confusion. Bool though? Float? Int? At that point you're just using var for the sake of using var rather than for the sake of making code readable.