Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Make JS and Boo deprecated in Unity 4. And non-functional in Unity 5

Discussion in 'Wish List' started by Meltdown, Apr 12, 2012.

  1. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,816
    I think we should have one language, C#.
    One set of tutorials for people to follow, and one unified codebase of examples and libraries.

    Not to mention it will take away all the confusion JS (JavaScript/UnityScript???) causes.
    Also what is Boo? Who is Boo? It just scares me at the thought. Is there even a Boo tutorial on the internet?

    All code should be written in intellisense aware editors, and in C#.

    One unified language, one great engine :rolleyes:
     
  2. OmniverseProduct

    OmniverseProduct

    Joined:
    Feb 26, 2012
    Posts:
    1,568
    I disagree on having only 1 language. Having multiple languages to choose from was one of the bigger reasons I came to Unity. Personally I think if you limit the languages you limit the audience. What if that person doesn't want to, or can't, learn C#? That would be one less customer that Unity could've had.

    I believe they should either do something different with Unityscript or add just Javascript. If Unity sticks with their version of Javascript then I believe a Markup Language should be added. Here's a list of Markup Languages in Wikipedia http://en.wikipedia.org/wiki/List_of_markup_languages

    As for boo, I don't know much on the language, but here is the website. The website has tutorials also. http://boo.codehaus.org/

    I agree that all code should be written in intellisense aware editors, but I disagree on just doing that in C#. All languages in unity, if possible, should be written this way.
     
  3. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    Sure, and while you're at it, why don't you outlaw OS X and Linux, and make all computers run Windows? Then you'd only need one version of programs, and wouldn't have to port anything. We don't need the confusion caused by diesel engines, either--get rid of that, and make everyone use petrol. For that matter, all those car brands are confusing--just outlaw everything except Ford, that way all car parts will work in all cars and you won't need a bunch of different dealerships.

    Sheesh.

    --Eric
     
  4. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,627
    What would be the benefit? The docs provide multiple examples right now. So I don't really see the problem.

    The real problem is that MonoDevelop needs to be more... Developed. It has little to do with the languages, its problems are more general.
     
  5. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    I'd agree to this providing it meant that the development time spent on boo and js was twice as efficiently spent on replacing monodevelop completely, and using a floating debugger that works with any ide we choose.
     
  6. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,816
    My reasonings for this are..

    1.) Today I spent 4 hours working in frustration with a library from the asset store written completely in js. I couldn't use intellisense in the js files, nor could I refer to items or objects in the js files from my C# files. It was like working with two different systems. In what took me 4 hours to do, if the library was in C# I could have done in 1.5 hours.

    2.) UnityScript/Javascript/WhateveruwannacallitScript is not a true OOP. It's not even a recognised language.

    3.) Boo is hardly used

    I really do understand that some people that come from certain backgrounds use certain languages etc.
    And some even say JS is easier to learn than C#. I really don't see this is the case. C# with intellisense is MUCH EASIER and MUCH MORE PRODUCTIVE to use than js without it.

    Almost every other engine out there uses one language. DirectX C++, Managed C#. XNA, C#. Essenthial C++ etc. etc.
    C++ and C# are now perhaps the most widely used languages. And most game engines use C++.

    I just honestly don't see the benefits of having multiple languages, over all the havoc and chaos it causes.

    I think a world in which Unity supported one language would in the long run be better for all. Imagine if every tutorial was in 1 language. i.e your language. You would find Unity easier to learn without scratching your head or using converters trying to remember or understand the differences. Companies and jobs for Unity would be a more focused skillset with people polishing their skills on one language.

    Sorry I honestly think the benefits far outweigh any advantages.
     
  7. ClarkCLK

    ClarkCLK

    Joined:
    Nov 21, 2011
    Posts:
    31
    now, in my project I do some UnityScripts and C# Scripts for programm...
    I havent idea how do something in C#? I'll do it on US.
    Its one of the bests points of unity.

    Wong Wong!!
     
  8. OmniverseProduct

    OmniverseProduct

    Joined:
    Feb 26, 2012
    Posts:
    1,568
    Just almost every other engine out there uses one language doesn't mean Unity has to. Just saying.
     
  9. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,816
    There is no such thing as can't learn a language.
    As for doesn't want to.. there aren't many games engines out there that support something other than C++.
    C# is much easier to learn than C++.

    A person is not going to not use Unity because it doesn't support Boo or Unity/JS script... they will use Unity because of how awesome it is and the multiplatform deployment.
     
  10. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,816
    The arguments for having multiple languages are not convincing enough for me or worth all the confusion/skill diffusion. Just saying.
     
  11. OmniverseProduct

    OmniverseProduct

    Joined:
    Feb 26, 2012
    Posts:
    1,568
    I disagree completely. What if said person knows Boo inside and out and Unity drops support for the language? I know I would leave in a heartbeat.
     
  12. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,816
    That is a good point. Although what engine are they going to go?
    The Scary Ghost Game Engine?

    Unity is not famous for it's language support. It's famous for being multi-platform and easy to work with.
    I guaranteee you if C# was the only language Unity supported it would be just as popular today. And there would be a lot less confused people out there and some really robust code libraries.
     
  13. OmniverseProduct

    OmniverseProduct

    Joined:
    Feb 26, 2012
    Posts:
    1,568
    I honestly don't know of any other engines out there that support Boo. I was just trying to make a point.
     
  14. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    Yes it is. It's factually incorrect to claim otherwise.

    What constitutes a "recognised language"? It exists, it's real.

    Unityscript is very similar to Actionscript 3; people coming from Flash learn it very easily in a small amount of time. Unityscript is more integrated with Unity and it's easier and faster to write Unity-specific code with it. C# is an "outsider" language and has to make compromises. You're exaggerating the "havoc and chaos" just because you were frustrated for a while because you didn't learn Unityscript.

    Sorry but no.

    --Eric
     
  15. JogwithAJ

    JogwithAJ

    Joined:
    Feb 27, 2011
    Posts:
    50
    Most likely blender, as blender uses phyton for scripting which is quite similar to Boo
     
    Last edited: Apr 12, 2012
  16. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,816
    Perhaps if all languages worked the same way in Unity, it would be better. If intellisense was supported transparently across languages, and you didn't have to put code in specific folders, and could have C# and JS files working side by side I would feel a lot better about it.
    I guess that is the frustrating part. I do know UnityScript, it really is a no-brainer to convert syntax between the two (except in some circumstances.). Although I just don't code in it, for said reasons.
     
  17. returnString

    returnString

    Joined:
    Jul 10, 2010
    Posts:
    248
    I tentatively support this thread. The gap between UnityScript and C# is not so large as some would make out, and C# is a transferable skill (obviously programming in general is too, but knowing what is arguably one of the most widely-used languages on the market helps).

    To me, UnityScript feels like an attempt to make people less afraid of programming by doing things like abstracting classes into the familiar concept of files etc (seriously, stop making me use separate files for components); I'm not entirely sure this is necessary.

    Oh man, developing debuggers for Mono embeds outside of MonoDevelop plugins is really dangerous business. It's possible to totally circumvent the Mono runtime for Windows and Visual Studio though iirc. Just not sure that would fit with UT's strategy...
     
  18. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    Then why did you claim it wasn't OOP? The main problem I have is that Unityscript is still not properly documented, despite UT saying they knew it was important and they had someone on it. I know from first-hand experience how time-consuming decent documentation is, but I also know from that experience that it should have been done by now.

    --Eric
     
  19. Jessy

    Jessy

    Joined:
    Jun 7, 2007
    Posts:
    7,325
    People should be able to use whatever they want, but cross-platform software cannot match the potential quality of the alternative. Porting is the devil. Buy a product that embraces competing paradigms if necessary.

    As for this thread, I don't think any of the languages that Unity supports should be. :-D
     
  20. kablammyman

    kablammyman

    Joined:
    Nov 22, 2010
    Posts:
    507
    LOLOLOLOLOLOL!!!!!

    anyway, I agree with this...kinda. Options are always good, and unity is a commerical product. Limiting options makes people upset, and causes you to lose business.
    HOWEVER (!!) in my unity experience, js scripts just messes things up in my project! We get these weird compile time issues, having to move scripts over otherwise they cant "see" each other and the tediousness of converting js to C#. Ugh! Unityscript also makes it real easy to make some crap code instead of having the structure and proper use ideals that a beginner should be learning (esp if hes working with other team members.)

    Sure, the unityscript syntax is similar t as3...but if a person isn't willing to learn a standard supported language like C# to make games (esp with something as easy to use as unity), then he/she probably should not be doing any coding anyway.
     
  21. zine92

    zine92

    Joined:
    Nov 13, 2010
    Posts:
    1,347
    To be honest, i learnt scripting/programming first from Unity's javascript and tutorials. So honestly i think javascript is an easier to grasp language than c# with all the extra stuffs. Might be good for people looking into doing some scripting.
     
  22. alexzzzz

    alexzzzz

    Joined:
    Nov 20, 2010
    Posts:
    1,447
    Options are not always good.

    From a consumer's point of view: It's much easier to choose between two sorts of cheese than twenty, especially if the only real difference is that some sorts of cheese stink while the others don't. The less sorts I see, the more chances I buy one.

    From a developer's point of view: What benefits I'll get, if I spend a part of my limited resources on a feature B that mostly duplicate the feature A I already have, instead of improving the feature A or making a new feature X?

    I see no significant difference between C# and UnityScript. The same concepts, the same base class library, the same amount of syntactic sugar. But interoperability really sucks, and US+MonoDevelop suck more often than C#+VisualStudio, so I prefer to translate or rewrite all the useful US scripts to C# and forget about US existence.
     
  23. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,830
    As I posted in the thread that started this:

    I might be able to support getting rid of US - there's very little to nothing it does well and there is a bunch of things it doesn't do well that among other things hurt the API.

    Boo on the other hand offers a different paradigm, and has nifty features like CaaS which would be awesome to use. What it needs is more tutorials etc into how to use it, rather than relying upon prior Python knowledge.


    To be honest - what can US do that C# can't? Very very little. Remembering that if U3D made the transition, they could adapt C#. For example:

    Code (csharp):
    1.  
    2. void Start()
    3. {
    4.     var x = 5;
    5.     var y = 5;
    6.     print(x+y);
    7. }
    could be a perfectly valid C#. There's no absolute requirement to have class, name space or import declarations - as my C# hero Jon Skeet notes in C# in Depth:

    One of the challenges when writing a book about a computer language (other than scripting languages) is that complete programs—ones that the reader can compile and run with no source code other than what’s presented—get long pretty quickly. I wanted to get around this, to provide you with code that you could easily type in and experiment with. I believe that actually trying something is a much better way of learning about it than just reading.

    With the right assembly references and the right using directives, you can accomplish a lot with a fairly short amount of C# code—but the killer is the fluff involved in writing those using directives, then declaring a class, then declaring a Main method before you’ve even written the first line of useful code. My examples are mostly in the form of snippets, which ignore the fluff that gets in the way of simple programs, concentrating on the important part. The snippets can be run directly in a small tool I’ve built called Snippy.

    If a snippet doesn't contain an ellipsis (...) then all of the code should be considered to be the body of the Main method of a program. If there is an ellipsis, then everything before it is treated as declarations of methods and nested types, and everything after the ellipsis goes in the Main method. So for example, consider this snippet:

    Code (csharp):
    1.  
    2. static string Reverse(string input)
    3. {
    4.     char[] chars = input.ToCharArray();
    5.     Array.Reverse(chars);
    6.     return new string(chars);
    7. }
    8. ...
    9. Console.WriteLine(Reverse("dlrow olleH"));
    This is expanded by Snippy into the following:
    Code (csharp):
    1. using System;
    2. public class Snippet
    3. {
    4.     static string Reverse(string input)
    5.     {
    6.         char[] chars = input.ToCharArray();
    7.         Array.Reverse(chars);
    8.         return new string(chars);
    9.     }
    10.     [STAThread]
    11.     static void Main()
    12.     {
    13.         Console.WriteLine(Reverse("dlrow olleH"));
    14.     }
    15. }
    In reality, Snippy includes far more using directives, but the expanded version was already getting long. Note that the containing class will always be called Snippet, and any types declared within the snippet will be nested within that class.

    There are more details about how to use Snippy on the book’s website (http://mng.bz/Lh82), along with all the examples as both snippets and expanded versions in Visual Studio solutions.


    -----------------------

    So yeah, between a U3D version of C# snippets, the 'var' keyword, some new default extension methods and some minor changes to the API... you'll quickly find there US really isn't that much simpler... but it is far more limited.
     
    Last edited: Apr 13, 2012
  24. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    Yes, actually, it is. The only people who claim otherwise simply don't know Unityscript very well. I don't even really blame them--as I said before, it's up to UT to document Unityscript properly, and they haven't. If you looked at all the ways it's simpler to use, for each one you'd say "but that's a little thing", which is true, but there are so many "little things" that it adds up to a fairly big thing. It's also a fair bit easier to screw up the syntax for C# because of all the extraneous fluff it forces on you, and the error messages frequently aren't helpful for figuring out what's wrong unless you have quite a bit of experience.

    Exactly how is it "far more limited"? Again, the only people who claim this just don't know Unityscript. It does have some limitations, indeed. It would be more accurate to say "it's a little more limited", but many of the limitations have been addressed as Unity has developed. The Unityscript in Unity 3.5 doesn't have most of the drawbacks it had in, say, Unity 2.6.

    --Eric
     
  25. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,830
    I'm happy to have such a discussion - while I don't claim to be a US expert by any means I have done some stuff in it.

    Every time I see a 'US is easier' claim, I try to do it in C#. Often I find it can be done similarly or even better with a properly considered C# alternative. So feel free to fire away with your concerns - and I'll try to address them.

    This is not to say there is nothing US can't do better - but I think that the list maybe much smaller than people might think. Then factor in the well discussed limitations [poor documentation, api, features, community division, lack of exernal use, confusion with js] and the picture isn't a happy one.

    Extension Methods, Generics, Events etc.

    Now I could be wrong here - but I'd consider the same reasoning that gave us a non-event driven GUI gave us US that doesn't support events. And, at least in my experience, the current way it is done is hideous. For example the [untested] following can fail:

    Code (csharp):
    1.  
    2. bool showButton = true;
    3.  
    4. void OnGUI()
    5. {
    6. ....
    7.     if (showButton)
    8.         if (GUILayout.Button("hideme")) showButton = false;
    9. ....
    10. }
    Which is just sad :(
     
    Last edited: Apr 13, 2012
  26. Jessy

    Jessy

    Joined:
    Jun 7, 2007
    Posts:
    7,325
    I don't agree with the majority of Eric's last post, but generics haven't been an issue for a while in UnityScript. Aside from the extra fluff that they require, over C#. ;-)
     
    Last edited: Apr 13, 2012
  27. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,830
    The ability to consume a generic is not the whole picture - unless I've missed a HUGE update in regards to creation.

    It's all about cost-benefit. Sure, US doesn't necessarily need Generics to be a 'scripting' language. and as long as it is a substantially easier scripting language, then the costs involved [both in dev time, and the split in resources and community] are worthwhile.

    However, with features from C# like 'var' and the slow depreciation of features from US like dynamic typing... suddenly you're still paying the cost but aren't seeing the benefit.
     
    Last edited: Apr 13, 2012
  28. Jessy

    Jessy

    Joined:
    Jun 7, 2007
    Posts:
    7,325
    Post C# you believe US can't replicate.
     
  29. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,830
    Code (csharp):
    1.  
    2.     public class GenericPool<T>
    3.     {
    4.         public int MaxSize { get; set; }
    5.         private Queue<T> items = new Queue<T>();
    6.         public T GetObject()
    7.         {
    8.             T item;
    9.             if (items.Count < MaxSize)
    10.             {
    11.                 item = default(T); //Create T - e.g. AddComponent or Instantiate Prefab.
    12.                 items.Enqueue(item);
    13.             }
    14.             else
    15.             {
    16.                 item = items.Dequeue();
    17.                 items.Enqueue(item);
    18.             }
    19.             return item;
    20.         }
    21.     }
     
  30. Jessy

    Jessy

    Joined:
    Jun 7, 2007
    Posts:
    7,325
    I never tried to use an interface in UnityScript before. The rest seems fine.
    Code (csharp):
    1. public class ObjectPool {   // implements IList = "Duplicate parameter name 'index'..."
    2.     var maxSize : int;  // No properties in UnityScript.
    3.     private var items = new Queue();
    4.     function GetObject() {
    5.         var item;
    6.         if (items.Count < maxSize) items.Enqueue(item);
    7.         else {
    8.             item = items.Dequeue();
    9.             items.Enqueue(item);
    10.         }
    11.         return item;
    12.     }
    13. }
     
  31. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,830
    Where's the generics?

    [Oh and the interface was removed as superfluous in this particular example, but I might bring that up later :p]
     
    Last edited: Apr 13, 2012
  32. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    OK, here's a partial list of things that annoy me about C# programming in Unity. This is actual stuff I actually do a lot, not just theoretical syntax games. (Well, I don't do a lot of threading, but I was doing some just recently.) As I said earlier, it all adds up when you spend hours doing this.

    Code (csharp):
    1. using UnityEngine;  // Useless fluff--we're using Unity, of course we're using the UnityEngine namespace
    2. using System.Collections;   // Same (because of coroutines)
    3. using System.Threading;
    4.  
    5. public class Stuff : MonoBehaviour {    // Again, fluff
    6.     public GameObject prefab;
    7.     public delegate void SomeFunction();    // Fluff, having to declare delegate types separately
    8.     public enum Foo {a, b, c}
    9.    
    10.     IEnumerator Start () {
    11.         SomeFunction aDelegate = Blah;  // Can't implicitly type here even if we want to. For some reason.
    12.         aDelegate();
    13.         var script = GetComponent(typeof(Stuff)) as Stuff;  // Useless fluff
    14.         // And no, GetComponent<Stuff>() is not the same.  It's slower.
    15.         yield return StartCoroutine (Thing());  // Yet more fluff
    16.         var number = 5.5f;  // Unity uses singles everywhere, having to put "f" in everything is annoying
    17.         var clone = Instantiate (prefab) as GameObject; // More fluff....
    18.         var go = new GameObject("go", typeof(Rigidbody), typeof(MeshRenderer), typeof(MeshFilter)); // Fluff!
    19.         var pos = transform.position;
    20.         pos.x = 5.0f;
    21.         transform.position = pos;   // I just wanted to change transform.position.x, why jump through hoops?
    22.         var thread = new Thread(ThreadFunction);
    23.         thread.Start(7);
    24.         int foo = 5 + (int)Foo.b;   // Have to cast every damn thing no matter how tedious or obvious
    25.     }
    26.    
    27.     void ThreadFunction (object x) {
    28.         int x2 = (int)x;    // Fluff, have to specify "object" for the parameter and then cast
    29.     }
    30.    
    31.     void OnGUI () {
    32.         GUILayout.BeginArea(new Rect(10, 10, 100, 50)); // Fluff, of course it's a *new* Rect
    33.         GUILayout.Label ("C# sure has a lot of fluff!");
    34.         GUILayout.EndArea();
    35.     }
    36.    
    37.     IEnumerator Thing () {
    38.         yield return null;  // More fluff
    39.     }
    40.    
    41.     void Blah () {
    42.     }
    43. }
    Compare to Unityscript:

    Code (csharp):
    1. import System.Threading;
    2. import UnityEngine.GUILayout;   // Can import classes
    3.  
    4. public var prefab : GameObject;
    5. public enum Foo {a, b, c}
    6.  
    7. function Start () {
    8.     var aDelegate = Blah;   // Can just do delegates without having to faff around
    9.     aDelegate();
    10.     var script = GetComponent(Stuff);   // Don't need fluff or slower generic version
    11.     yield Thing();  // Much simpler, and "yield" makes it obvious it's a coroutine
    12.     var number = 5.5;   // Don't have to put "f" everywhere
    13.     var clone = Instantiate (prefab);   // Simpler
    14.     var go = new GameObject("go", Rigidbody, MeshRenderer, MeshFilter); // No useless "typeof" everywhere
    15.     transform.position.x = 5.0; // Much nicer...the point of Unity is that it jumps through a lot of hoops for you
    16.     // Otherwise you might as well make your own engine. Besides, you can still do things the long way if needed.
    17.     var thread = new Thread(ThreadFunction);
    18.     thread.Start(7);
    19.     var foo = 5 + Foo.b;    // Don't have to cast everything everywhere
    20. }
    21.  
    22. function ThreadFunction (x : int) {
    23.     // Can just specify the type for paramaterized threads, no need for casting object
    24. }
    25.  
    26. function OnGUI () {
    27.     // We imported GUILayout, no need to spray "GUILayout." everywhere
    28.     BeginArea(Rect(10, 10, 100, 50));   // No need for "new" everywhere either
    29.     Label ("Unityscript sure is nicer! Mostly!");
    30.     EndArea();
    31. }
    32.  
    33. function Thing () {
    34.     yield;  // Just yield. No fluff.
    35. }
    36.  
    37. function Blah () {
    38. }
    And yes, there are some things that annoy me about Unityscript compared to C#. It is, for sure, not perfect. But the C# annoyance list is a lot longer.

    --Eric
     
  33. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,816
    US doesn't support support abstract classes, interfaces, and supports only single inheritance.
    I'm not sure if this has changed though, as I don't keep up to date with it.

    Sure it may be 'OOP' in a sense of the word, but it still lacks core OOP features that C# supports.
     
    Last edited: Apr 13, 2012
  34. SteveJ

    SteveJ

    Joined:
    Mar 26, 2010
    Posts:
    3,085
    Interesting topic. I've done projects in both full UnityScript and full C# - I was initally inclined to agree with the OP as I primarily use C# , but Eric has me half believing that I should switch to UnityScript as my primary language - some pretty good arguments :)

    I don't really think languages mean all that much to Programmers - they've definitely never meant much to me. Learning syntax for a new language is - in most cases - a couple of days work at the absolute most. I think the problem - or the CHOICE - is more a matter for non-programmers who are attempting to dive in and write games solo - i.e. the people who come to Unity from non-development backgrounds who are just wanting to make games (hobbyist, start-up indie, etc). In that case, I think giving them a choice isn't a bad idea, though inevitably it seems that most will go with UnityScript as it's perceived as being "easier".

    Anyway, if Unity was a new tool and they were taking votes for the ONE language they should support, my vote would be for C# purely because it is a language that can directly be used elsewhere. Given that they already support multiple languages though, I don't think there's any valid reason to remove any of them unless doing so would mean significant improvements in other areas of the product (which I don't think would be the case).
     
  35. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    By any standard definition. Besides, C# doesn't support multiple inheritance.

    I'm not trying to get anyone to switch. ;) I just want the more militant C# proponents to ditch their "one true way" mentality. It's no more flattering or useful coming from programmers than it is coming from religious proselytizers.

    --Eric
     
  36. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,816
    Ah well.. it was worth a try :rolleyes:
     
  37. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,830
    Hi Eric, let's take a look at your problems:

    Code (csharp):
    1.  
    2. using UnityEngine;  // Useless fluff--we're using Unity, of course we're using the UnityEngine namespace
    3. using System.Collections;   // Same (because of coroutines)
    4.  
    5. public class Stuff : MonoBehaviour {    // Again, fluff
    6.  
    I understand these problems. So why don't we simply do the rational thing and leave it out? This is not US vs C# but unity3d being lazy. It would be simple to create a '.cssnippet' format that with a click of button can be converted to standard 'cs' and vice versa - so you can still work with VS [at least, until a plugin supporting snippets is realeased for VS :)].

    Code (csharp):
    1.  
    2. public delegate void SomeFunction();    // Fluff, having to declare delegate types separately
    3.  
    Then don't declare delegate types - they are no longer a necessity with the included Action<> and Func<>.

    Code (csharp):
    1.  
    2. var script = GetComponent(typeof(Stuff)) as Stuff;  // Useless fluff
    3. // And no, GetComponent<Stuff>() is not the same.  It's slower.
    4.  
    You chose a marginally faster implementation that's much more complicated? EasyFix.
    http://pastebin.com/WPbrbPJ0

    Code (csharp):
    1. yield return StartCoroutine(Thing());  // Yet more fluff
    Interesting... I need to think about this. There may be a better way.

    Code (csharp):
    1.  
    2.  var number = 5.5f;  // Unity uses singles everywhere, having to put "f" in everything is annoying
    3.  
    lol.

    Code (csharp):
    1.  
    2.  var clone = Instantiate(prefab) as GameObject; // More fluff....
    3.  
    Why not use generics or create a GO.Create() function?

    Code (csharp):
    1. var go = new GameObject("go", (Rigidbody), typeof(MeshRenderer), typeof(MeshFilter)); // Fluff!
    Again, this is the API, not the language.

    You could do:

    Code (csharp):
    1. GameObject<Rigidbody, MeshRenderer, MeshFilter>("go");
    Amongst other things.

    Code (csharp):
    1.  
    2. var pos = transform.position;
    3. pos.x = 5.0f;
    4. transform.position = pos;   // I just wanted to change transform.position.x, why jump through hoops?
    5.  
    True... I'd probably do the following:

    Code (csharp):
    1.  
    2. transform.x = 5;  //or
    3. transform.SetX(5);  //or
    4. transform.PosX(5);  //Depending on how you want your naming to work.
    5.  
    Code (csharp):
    1.  
    2.  int foo = 5 + (int)Foo.b;   // Have to cast every damn thing no matter how tedious or obvious
    3.  
    That's one thing I'd disagree with - one has to be careful with enum <> int conversion. However, if you're bored you can go and actually get implicit typing to work. The better solution is to use a static class with const's. http://stackoverflow.com/questions/...-an-enum-value-when-i-try-to-use-or-return-it

    Code (csharp):
    1.  
    2. GUILayout.BeginArea(new Rect(10, 10, 100, 50)); // Fluff, of course it's a *new* Rect
    3.  
    Can't think of anything off the top of my head to help with the new structs.

    Code (csharp):
    1.  
    2.     IEnumerator Thing()
    3.     {
    4.         yield return null;  // More fluff
    5.     }
    Meh, I'll give you that one.

    So I've managed to get it down to:

    Code (csharp):
    1.  
    2. using System.Threading;  //Default Rubbish removed
    3. using GL = UnityEngine.GUILayout;  //Alias's are possible
    4.  
    5.     public GameObject prefab;
    6.     public enum Foo { a, b, c }
    7.  
    8.     IEnumerator Start(){
    9.         Action aDelegate = Blah;
    10.         aDelegate();
    11.         var script = GetComponent<Stuff>();
    12.         yield return StartCoroutine(Thing()); //Working on it
    13.         var number = 5.5f;
    14.         var clone = Instantiate(prefab); //Generic Solution
    15.         var go = GameObject<Rigidbody, MeshRenderer, MeshFilter>("go");  //Genrics FTW
    16.         transform.SetX(5);
    17.         var thread = new Thread(ThreadFunction);
    18.         thread.Start(7);
    19.         int foo = 5 + (int)Foo.b;   //Leave as is for now.
    20.     }
    21.  
    22.     void ThreadFunction(object x) {
    23.         int x2 = (int)x;   //Problem with the old Threading API - Need to look for modern fix.
    24.     }
    25.  
    26.     void OnGUI() {
    27.         GL.BeginArea(new Rect(10, 10, 100, 50)); // Fluff, of course it's a *new* Rect
    28.         GL.Label("C# sure has a lot of fluff!");
    29.         GL.EndArea();      
    30.     }
    31.  
    32.     IEnumerator Thing(){
    33.         yield return null;  // Minor Fluff.
    34.     }
    35.  
    36.     void Blah(){
    37.     }
    38.  
    This needs a lot more work done - but does show you that the 'gap' between US and C# isn't as great as you thought.

    What I want to do, if this was serious, is gather together everything US can defiantly do better, what C# defiantly can do better and what is 'meh'. My preliminary findings is that US is much weaker than many thought [e.g. transform.position.x = 5 is the LONG way to set x!]
     
  38. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,830
    The only religious bollocks is the anti-religious bollocks coming from some members of the US camp :p
     
  39. Jessy

    Jessy

    Joined:
    Jun 7, 2007
    Posts:
    7,325
    I forgot that Queue came in a non-generic variant. I couldn't figure out any way to match your code after I realized that boxing was going on.

    Those names are horrible! :-|
    Code (csharp):
    1. public static void SetPosition (this Transform transform,
    2.     float? x = null, float? y = null, float? z = null)
    3. {
    4.     Vector3 position = transform.position;
    5.     if (x.HasValue) position.x = x.Value;
    6.     if (y.HasValue) position.y = y.Value;
    7.     if (z.HasValue) position.z = z.Value;
    8.     transform.position = position;
    9. }
    I wish there was some way to combine UnityScript's avoidance of the limitations of properties with this swizzle-esque ability though:
    Code (csharp):
    1. transform.SetPosition(x:3, z:5);
    If UT could keep feature parity between UnityScript and C#, it would be a different story.
     
    Last edited: Apr 13, 2012
  40. BrynP

    BrynP

    Joined:
    Mar 7, 2012
    Posts:
    49
    I think at the end of the day supporting them offers choice. Not everybody likes using C# and not everybody likes US, but at least people have a choice as to what they prefer to use. Personally, I love C#, I think it's awesome. But I've encountered people with a difference of opinion on that and they're welcome to it. US might be better for some people and if this wasn't the case, C# users wouldn't have to sit around and translate from US because clearly C# would be the better option for everyone. I don't think it's a question of learning resources either, sure the Lerpz tutorial is in US, but there's also an array of decent (if not better) Unity3D C# tutorials out there and the code reference is in C# US. Of course, I'm sure US users encounter the same problem.

    As for what is 'better', I think it's reminiscent of the pointless Mac vs PC debates out there, because regardless of what languages does what more efficient or what features are better or what's more convenient, because the programmer will have their personal preferences.
     
  41. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,830
    Exactly. It's not just boxing [though that's important to note] - but the lack of strong typing.

    Nice :)

    This is why I like C# - inventive problem solving, rather than relying on the couple niceties already built in. Though I *might* have tried to use a magic value [e.g. nan] instead of boxing for performance reasons. Hmm... should benchmark that.

    What US needs, if it wants to continue to exist, is MORE FEATURES. "cause - baring an amazing rebuttle, it's not shorter than C#, or fast, or simpler in many many regards - both simple and complex code. It's almost as if the U3D team is holding C# back to give US some differentiation.

    I know I'm going to cop some flack for that - and bring it on. But take a look at how things could be done vs how they are - and there's a lot of improvements that could be made. Creating US snippets but not C# snippets isn't a smart decision if you think about it.

    Disclaimer: This isn't a deliberate choice on U3D's part [at least I hope not] - just an interesting turn of history.
     
    Last edited: Apr 13, 2012
  42. alexzzzz

    alexzzzz

    Joined:
    Nov 20, 2010
    Posts:
    1,447
    Code (csharp):
    1. public static class Extensions
    2. {
    3.     public static T Replicate<T>(this T sample) where T : Object
    4.     {
    5.         return (T) Object.Instantiate(sample);
    6.     }
    7. }
    The problem solved once and for all.

    Usage:
    Code (csharp):
    1. var clone = prefab.Replicate(); // Short and type-safe
     
  43. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    What about people who can code C++ fine but love unity js? That'd be me.

    I accept it is in fact limiting compared to C++ - there's some limits to it such as getters and setters not functioning correctly and presumably you can probably still use pointers (maybe it's faster for some magical thing someone wants to do).

    But I like the simplicity of just... coding. There's no thinking about anything, just throw it out there and iterate. UJS has that brainlessness I really enjoy.
     
  44. Jessy

    Jessy

    Joined:
    Jun 7, 2007
    Posts:
    7,325
    This should be unnecessary. The docs list a generic form of Instantiate, which should match this. But it doesn't work.
     
  45. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    Sorry, but you didn't actually address any of my issues with C#. Except Action--that was valid. None of the others were. Things like using an alias instead of importing the class--I know about that, and it doesn't really help. It just shortens things a bit, and confuses the issue, rather than actually doing what Unityscript does more easily (and your example was especially poor since GL is already a class in Unity). You either dismissed my issues as irrelevant (which I *knew* you were going to do--but I'm the one working on my code, not you--I get to decide if they're relevant, not you--saying "meh" just concedes the point), or you tried to sidestep them by creating other functions, which doesn't actually address the issues. I can write a bunch of functions in Unityscript too; that's really not the point. The point is the standard, built-in behavior. So yeah, not convincing at all, sorry. (The word, by the way, is "definitely", not "defiantly".)

    --Eric
     
  46. polytropoi

    polytropoi

    Joined:
    Aug 16, 2006
    Posts:
    681
    No, sorry - you're the extremist, whereas Eric is advocating tolerance.

    Me, I think they should get rid of C# and ban it's mention from the forums, and revoke the licenses of people that use it, and put them in a dungeon and gently flog them until they sincerely admit that they are wrong. :)
     
  47. alexzzzz

    alexzzzz

    Joined:
    Nov 20, 2010
    Posts:
    1,447
    In reality there's no generic form:

    $reflector.PNG

    Anyway prefab.Replicate() is shorter than Instantiate<GameObject>(prefab), there's no need to specify the type.
     
  48. Jessy

    Jessy

    Joined:
    Jun 7, 2007
    Posts:
    7,325
    I'm not arguing against your syntax. I think it's the best option that C# offers, and should be in the API. However, I am arguing that another name is unnecessary. There's no reason to call it "Replicate" instead of "Instantiate".

    Not with the brevity that you prize. Or maintainability. Your examples favor UnityScript, but they represent too small a subset of software construction. All of your syntactical arguments will be trifles unless UnityScript can match the functionality of C#. The languages are too similar for UnityScript to be a rational choice at present. Boo might be worth supporting, but nothing is helping any of us make that assessment, so I have no opinion on it. UnityScript comes off as a pointless endeavor to me.
     
    Last edited: Apr 13, 2012
  49. ColossalDuck

    ColossalDuck

    Joined:
    Jun 6, 2009
    Posts:
    3,246
    I have a sudden urge to punch you... huh.



    Anywho, I really don't think any language should be removed in Unity. Choice is good. All you people are doing is arguing like religious people do over which God is real.

    In the end, all the languages will get the job done.
     
  50. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    Again, you don't get to decide what a "trifle" is for me. I already mentioned to start with that most of those things taken individually wouldn't be that big a deal, it's all of them together, constantly, that gets wearying.

    So don't use it; I wouldn't try to convince you that you should. But don't be one of those people who doesn't understand the concept of "difference of opinion". You're not "right" about C#, you just have an opinion. At the end of the day, it's about using whatever tool that helps you actually get something out the door.

    --Eric