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

Nonsense. It's a message of hope. Sure, those two fight over using linq, and seem to be enemies. But anyone else looking at the two versions of that code sees two good friends, united in their over-use of "var".

 

It offers a slight advantage on reducing refactoring time if code changes.

Example:

Code (CSharp):

1. var myCollection = ComplexGetCollection();
2.  
3. foreach (Thing thing in myCollection){
4.     thing.DoSomething();
5. }

I can change ComplexGetCollection to return any type of collection without needing to also refactor the consuming code. Its really useful for third party libraries which can return some really bizarre and types.

 

It's just unnecessary obfuscation out of laziness of putting in the type that you know is going to be used and would make it quicker to see in all cases... instead of looking at what is being assigned, sure true/false for a bool, just bad habbits imo.. reminds me of how much I hate javascrap developers and google mostly for just existing tbh

 

Fairly certain var was added to support Anonymous Types.

 

I asked politely not to bring that discussion. So why replaying?
You need recognize preferences, not impose your view.

I said for me not using vars are easier to read.
I know when or where certain types are.
What need be in future.
Reduces risk of error.

Specially useful for writing modding tools / scripts, eliminating unnecessary questions and errors from modders.
Data type carry valuable information by itself, specially when have no access to intellisense.
For example viewing code on github.

 

Lol. Hate is a strong word.

Dynamic typed languages do have their place in the world. They are perfect for UI's which databind their models to the view. Look at MVC, WPF etc., they have tons of close to the metal hacks to let a static language like C# databind dynamic to the view.

Also var and javascript as nothing in common. Var in C# only hides the type, all the type safety of static c# is there.

 

This has proven to be the other way around actually.

 

Need more context, are you setting a member on self?

 

where

 

Words thrown on wind.

 

Its consensus among everybody remotely senior in the corp.business world. That and writing comments

 

Do you actually respond to indirectly to my question, which was related to modding, not some senior business unrelated crap?
We had discussion about seniors in past, and arena is well divided. And is not what I was referring to.

 

I would say it applies to any domain logic

 

Okay show me something where somebody actually checked though. If seniors knew everything we wouldn't still rely on fax machines for sending legal documentation in North America. I remember a lot of seniors also used to say that doing anything outside of the command line was "too slow to ever catch on."

 

Ah I think I should drop out at this point, its clear that I have no idea what I'm talking about (I thought I was on the same topic). I may be comparing oranges to apples in my scenario I gave.

 

Ok, however,

Where:

I need highlight word FOR ME.
I don't care about seniors dinosaurs and theirs approaches.

So please don't try rip more convenient part of the context, just to prove yourself right.
Try at least stay on the topic of responder.


Lets cut it here ...

 

haha, thats just north america being north america. You guys dont even have a common electronic way to identify yourself

 

You can't assume that "consensus among everybody remotely senior in the corp.business world" automatically applies to any other situation, especially a situation like game development. In the business world, the code priority is often making sure it delivers the correct answer, but in the game dev world performance takes a priority. Anything you do to make the code short and simple for the programmer will risk reducing performance and potentially hiding potential performance tweaking opportunities.

At a bare minimum, you need to profile your code changes to make sure you did not cause a performance problem by trying to apply business world practices to another domain. But beyond that, you also need to re-think your constant desire to hide information from yourself. For example, by hiding variable types (using var), you will likely miss opportunities to come up with performance tweaks that may be specific to what ever combination of type and use case you are dealing with.

Similarly, by refactoring loops into linq style code, you are hiding potential places where you could potentially exit a loop early for example. Not to mention that fact I personally tend to avoid using foreach at all when doing game dev work. I strongly prefer iteration using an int based index of the array or list, and I like to setup a dictionary or hash table to provide rapid lookups of an index based on other parameters. For example, instead of using foreach to go through a list of connected players, I will lookup the player's index number based on their network endpoint and then I will use that index number to instantly grab the player data from a list or array.

 

LINQ allocates, never use Linq from loops that needs to be kept tight. Our domain is very, very optimized. 95% of the time clean code does not affect performance though. Its all the small things that add up, like doing early exits instead mid method exists, etc. to the bigger things like using proper abstraction, SOLID approaches.

Oh, and offcourse always profile, and never use a method you haven't written without first looking up its complexity

 

Sure, do that for now. But the next step, which a typical junior-level course covers, is to look at the underlying data structures. You almost always have an array, a linked-list, or a hash table. Then more rarely some sort of balanced tree. If you know that, you don't need to look at running times or do as much testing.

For example, the only thing to know about the C# List class is it's an array. Now you know insert and delete are a slow O(n) anywhere except at the back, which is O(1).

 

Always check MSDN for the complexity. For instance Linked list is O(1) if Remove(Node<T>) but O(n) if Remove(T) which is not that strange since the latter needs to find the Node than remove it. but still always check MSDN when using third party libraries.

 

Actually, the C# List class is a linked list, not an array. It functions somewhat similar to an array, but it is different. Since C# List is a linked list implementation, it is generally slower than an array when doing enumeration. With an array, all items are stored sequentially in memory. With a linked list, each item contains it's data plus a pointer to the next item. With linked lists, items can be scattered throughout memory.

 

List of T is not a linked list

https://referencesource.microsoft.com/#mscorlib/system/collections/generic/list.cs,cf7f4095e4de7646

 

List is kinda array internally. At some point in .Net you even were able to get that internal array.
Nowadays - hard to tell. I'd still bet its some kind of unsafe array with lots of optimizations.

 

Sure, list-remove can be sneaky when you're first learning it. But those are the normal times for all linked lists. If you've used them before, all you need to know about the C# LinkedList class is it's a linked-list. Then you know everything in the manual about it.

And then, standard PSA: running times only matter for a few parts of your code. If you have at most 10 weapon types, nothing you do for weapons swaps will be all that slow. Or, those 2 versions of the refactored code above appear to be setting up buttons for a menu. Speed won't matter. It probably has a delayed "pop-in" effect anyway. Anders's probably runs a tad slower, but (I'm assuming) is easier to read, so easier to add to later.

 

You always need to weight maintainbility over speed. Most often speed doesn't matter, o(100) is nothing for a modern CPU. Though, continues allocation must be avoided at all costs even more so in mono since it's alot slower than .NET CLR.

 

I thought big O notation was for the shape of the curve rather than actual number of operation (ie if it is linear, exponential or logarithmic)

 

Don't be too harsh, the "consensus among everybody remotely senior in the corp.business world" does not matter this time.

 

O(1) means constant lookup.

 

Yeah, we all know that, but what O(100) means?

 

Well you guys are being anal so I'm anal too, he talked about curves and O(1) is not a curve
I didnt write O(100) i wrote o(100) its O(n) where n = 100 and yes, I just made that notation up

 

I may be wrong, but my impression was, that this was genuine question, not trolling.

Which I think it didn't really answer it?

 

This time, you're wrong. I know what the notation usually says.

Oh, he did:

 

Oh never mind then
Ignore me and carry on ..

 

Haha, this is what we in Swedish calls meta discussion

 

Little-o is already used, but you only see it in proofs. It means "no less than this." For example bubble sort is o(n), since it might quit after one pass, but selection sort is both O(n^2) and also o(n^2), since it always runs the same nested loops no matter what.

For something cool, look up how C# (or any language) does sorts. It sort of explains the big-O constants weirdness. They use an O(n log n) sort at first, like merge sort. That gives you smaller and smaller lists. But when a sublist gets below size ~20, they switch to a "slow" O(n^2) sort since the constant is lower. It's like how driving is faster than walking, except for less than a block, walking is faster.

 

Well, apparently I'm not alone with my grudge against mindless abstraction and preference towards utilities...

 

Yep I watched that full before. Good talk.

Well definitely not.
I share your pain

 

I felt like the point in that talk is you keep the apple (c# monobehavior pragmatic) and eating it (ecs performance) at the same time, which allow you to ignore one principle for the other by simply having multiple options (ie you have multiple apple).

I'm saying that as a way to probe what are your consensus and further my understanding of how many programmer feel.

 

I wrote two comments today, probably more than I did under all of 2018 and I thought about this thread

Code (CSharp):

1.     [CreateAssetMenu(menuName = "Tutorial/Interact")]
2.     public class InteractStep : TutorialStep
3.     {
4.  
5.         public string ItemType;
6.      
7.         public override IEnumerator Execute()
8.         {
9.             if (topItem != null)
10.             {
11.                 ShowPopup(topItem.ColliderParent.transform, GetGrabText());
12.  
13.                 while (topItem && !topItem.IsAttached)
14.                 {
15.                     yield return null;
16.                 }
17.                 yield return null; //Give SteamVR a frame to active action set on grabbed item, its a bug in SteamVR 2.2 that does not let you call action.GetLocalizedOriginPart in the same frame after you have activated the action set
18.             }
19.         }
20.      
21.  
22.         protected virtual string GetGrabText()
23.         {
24.             return string.Format("Grab the {0} by {1}.", ItemType ?? "[name]", GetInteractionCaption(topItem.ItemType));
25.         }
26.     }

Code (CSharp):

1. public IEnumerator Execute()
2. {
3.  
4.     foreach (var prefab in Steps)
5.     {
6.         var step = Object.Instantiate(prefab);
7.         currentStep = step;
8.         yield return Execute(step);
9.         currentStep = null;
10.     }
11.  
12.     NVRPlayer.Instance.Inventory.DropAllItems();
13.     CleanupItems();
14.     yield return null; //Give PhysX a frame to remove Rigidbodies and Colliders. Otherwise if we spawn a new object in its place it will be moved by the removed item          
15. }

 

Its not only me that think on maintainability. In the latest version of resharper this happens when you write inline variables that are sent directly to methods

 

Pointless necro. Closing