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. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    Tell that Unity, i am the wrong person. I call it whatever they have named it. And they called it JS.

    What`s a bit sad is that Unity is a bit resistent for good suggestions. There was for example the idea to allow comments at the scripting reference. Which would have helped alot.

    Anyways, i`m with you with that wish for a better documentation. That it is a bit weak doesn`t mean that you should kill the complete language though. That just means to give the language a better documentation.

    C# may dominate outside Unity. But not inside Unity. Inside Untiy JS is still better documented in terms of existing snippets in the manual and the scripting reference than C#. And i am absolutely not interested in outside. I make a game with Unity. Not a calculator with C#.

    JS is a more than useable language. I have no problems to use it. For me it does the job, better than C#.

    And again, i have no problem that you and others prefer C# over JS, that you think that it is more powerful, better, the world saving, the one and only god. But it is not my opinion. Not my experience. And when you want to take me that away then i will resist.

    I`m with you though that Unity should stay at the state of the art side when it comes to languages. When you miss a feature, then poke them to get it.
     
    Last edited by a moderator: Apr 23, 2012
  2. c-Row

    c-Row

    Joined:
    Nov 10, 2009
    Posts:
    847
    Hey, some of us have 9-to-5 jobs, too. ;)


    I have read about that option of course, but that's just too many hoops to jump in my opinion.
     
  3. c-Row

    c-Row

    Joined:
    Nov 10, 2009
    Posts:
    847
    Another thing whose benefit in C# I didn't quite understand was that one of my functions which worked fine in US didn't work until I added IEnumerator to its header - something US did pretty well without.
     
  4. Tseng

    Tseng

    Joined:
    Nov 29, 2010
    Posts:
    1,217
    That's no argument, it's your your will/desire. Despite this fact, are you so ignorant, that you you got blinded by your hated, that you haven't even realized that I no where in this thread suggested or agreed with the removal of US/Boo???

    I personally couldn't care less if they drop US/Boo support, though that's just my personal opinion and not an argument. If you take the time to read this to the end then, you'll see that I said several times, that introduction of UnityScript was an strategical error which backfired. S*** happens. But UnityScript CAN NOT BE REMOVED AT THIS POINT OF TIME. It's simply too late and UT has to support it. I'm realistic. I know that deprecation in Frameworks is something very difficult. It's already hard enough to deprecate certain methods or classes from a framework, but deprecating a whole language is next to impossible in UT position

    However what they can do is: enhancing UnityScript (and probably boo) to some point which allows UnityScript to do the same things C# can do. Than you still have two different flavors, but they support the same feature set. And this in turn would allow to design a clean and flexible Unity API (Reminder for you: API is independent of the language used) for the next major release (Unity 4).

    This of course means, that current 3.0 projects wouldn't most likely break when imported in Unity 4 and some changes will be necessary due to a new API, but that's an acceptable risk, as major versions are already a signal of incompatibility, but in the long term it will enrich the whole Unity community (Unity 2 to 3 job was a breaking change too and most projects done with 2.x required some code changes to work with 3.x).

    That's what I got from the docs, as there was no @Serializable attribute in US.

    But I had a "TestObject.js" script which the same 2 public variables, without declaring it as class and it's members were not exposed, I just had the typical "Drag drop" field where you can drag objects from Scene/prefabs from projects into them if they had the TestObject script attached


    Had a similar issue just a few moments ago (though not with nested classes, but while the class was defined in it's own file... which btw. is the encouraged way of doing it: 1 class = 1 file (or 1 class = several files, i.e. partial classes)). The Inspector would stills how the list as "TestObject" (with the typical drag and drop inspector field). After detaching the test script from the Object and reattaching it, it correctly exposed the serialized attributes.
     
    Last edited: Apr 23, 2012
  5. Diviner

    Diviner

    Joined:
    May 8, 2010
    Posts:
    677
    Just curious here, not taking any sides, but why does everyone forget the Function type pseudo-delegation in Unityscript when they mention that US can't handle events? I've written a complete event system in US and works just fine (even added the += / -= operations that standard Function types lack).
     
  6. Tseng

    Tseng

    Joined:
    Nov 29, 2010
    Posts:
    1,217
    I personally heard of it for the first time, some pages ago (I think it was on page 3 or 4) in this thread as it's obviously undocumented
     
  7. c-Row

    c-Row

    Joined:
    Nov 10, 2009
    Posts:
    847
    No, still no luck. I got the clsItem class in a separate file now...

    Code (csharp):
    1.  
    2. using UnityEngine;
    3. using System.Collections;
    4.  
    5. public class clsItem : MonoBehaviour {
    6.    
    7.     public new string name;
    8.     public int weight;
    9.     public Transform prefab;
    10.     public int worth;
    11.  
    12.     // Use this for initialization
    13.  
    14.     void Start () {
    15.    
    16.     }
    17.  
    18. }
    19.  
    ... and set up a GenericList in my ItemManager...

    Code (csharp):
    1.  
    2. using UnityEngine;
    3. using System.Collections;
    4. using System.Collections.Generic;
    5.  
    6. public class ItemManager : MonoBehaviour {
    7.    
    8.     public List<clsItem> myItems = new List<clsItem>();
    9. ...
    10. }
    11.  
    ... but the Inspector still only shows the drag&drop field you described, even after freshly reattaching it to my GameObject.
     
  8. Tseng

    Tseng

    Joined:
    Nov 29, 2010
    Posts:
    1,217
    That's because you derive it from UnityEngine.Object (MonoBehaviour > Behaviour > Component > UnityEngine.Object). The inspector will make it as drag drop.

    when you remove the ": MonoBehaviour" from "clsItem" (btw. we don't prefix classes in C#, all classes start with Uppercase Letter, because it can be easily confused with a variable when you use a lowercase/prefix) then it won't display at all in the Inspector. Unless you add [System.Serializable] to the "clsItem" class

    P.S. this is equal
    Code (csharp):
    1.  
    2. // C#
    3. public class Item {
    4. ...
    5. }
    6.  
    7. // Unityscript
    8. class Item extends System.Object {
    9. }
    10.  
    The reason for it is that any component or GameObject etc. derives from UnityEngine.Object.

    UnityEngine.Object in turn is derived from System.Object, because every Type in .NET derives from System.Object, even int, float, doubles and string.
    This is very different form Java. In Java (NOT JS/US) you have classes and complex types which derive from Object, while primitives (int, float, double, byte) are not derived from Object.

    This makes boxing of complex and primitive types impossible in java (or more complex as you can see in the example)

    Code (csharp):
    1.  
    2. // Java
    3. int number = 5;
    4. Integer number2 = new Integer(number);
    5. TestObject to = new TestObject();
    6. ArrayList list = new ArrayList();
    7. // fails, because int is a primitive not an Object
    8. list.add(number);
    9. // works, because Integer is a class which derives from Object, but int doesn't
    10. list.add(number2);
    11. // works
    12. list.add(to);
    13.  
    One of the major flaws of Java language, which is some of the burdens Java has to carry with for compatibility reasons
     
    Last edited: Apr 23, 2012
  9. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    LOL

    I told you ;)

    But you are yelling at me without reason, acting like a C# fanboy. Which is the same in a thread where it`s about the removal of JS and BOO. And it`s not the first time that we two have a conversation. Better said that you are holding one of your monologues, ignoring every argument.

    Not everybody works the way you do. When you are really hating here then you have a serious problem. Which i think you have anyways. But that`s just my personal opinion, and no argument.
     
  10. alexzzzz

    alexzzzz

    Joined:
    Nov 20, 2010
    Posts:
    1,447
    It's another doubtful feature of US - function's return type is optional.

    Code (csharp):
    1.  
    2. // You can write
    3. function Foo() : int
    4. {
    5.     return 0;
    6. }
    7.  
    8. // Or you can write
    9. function Bar()
    10. {
    11.     return 0;
    12. }
    They are the same, the only difference is that Bar's return type is not specified explicitly. It's fine if your function is three lines long, but if it's more complex you'll never know what the return type is until you scan through all the function to find a 'return' statement.

    Now imagine you've encountered something like this:
    Code (csharp):
    1. function Foo()
    2. {
    3.    ...
    4.     return Bar();
    5. }
    I hate this US's feature. In order to know what the return type or Foo is, you have to know what is the return type of Bar. Or maybe the return type is Bar?
     
    Last edited: Apr 23, 2012
  11. c-Row

    c-Row

    Joined:
    Nov 10, 2009
    Posts:
    847
    Well, this works now...

    Code (csharp):
    1.  
    2. using UnityEngine;
    3. using System.Collections;
    4.  
    5. [System.Serializable]
    6. public class Item {
    7.    
    8.     public string name;
    9.     public int weight;
    10.     public Transform prefab;
    11.     public int worth;
    12.  
    13.     // Use this for initialization
    14.  
    15.     void Start () {
    16.    
    17.     }
    18.  
    19. }
    20.  
    ... but I still don't see why C# needs me to add the [System.Serializable] even though everything is as "public" as possible.
     
  12. Diviner

    Diviner

    Joined:
    May 8, 2010
    Posts:
    677
    Because public is not the same thing as serializable. Public is an access level. Serializable is a class attribute. A property needs to be public and serializable to be displayed in the Inspector. Unityscript automatically adds Serializable to all custom classes, and all properties are public by default. C# works the opposite way. All properties are private, and in custom classes you need to explicitly add the Serializable attribute.
     
  13. Tseng

    Tseng

    Joined:
    Nov 29, 2010
    Posts:
    1,217
    As I said, C# is very pragmatic. By default classes don't need to be serialized and it's there to prevent mistakes, because not every class can be meaningful serialized (i.e. there are some fields which can't be reconstructed and must specifically be marked as NonSerializable).

    Usually Serialization is used for data objects (i.e. to map a database row into one class)
    Code (csharp):
    1.  
    2. [Serializable]
    3. public class Person {
    4.     public long ID { get; set; }
    5.     public string Name { get; set; }
    6.     public string Street { get; set; }
    7.     public string Zip { get; set; }
    8. }
    9.  
    This can easily be converted into XML and from XML into a class using XmlSerializer for example. But sometimes you want to serialize data which is not just a class with only fields and properties.

    Code (csharp):
    1.  
    2. public class Player {
    3.     public int Name { get; set; }
    4.     private int maxHealth;
    5.     public int MaxHealth {
    6.         get { return maxHealth; }
    7.         set {
    8.             if(maxHealth < 1)
    9.                 maxHealth = 0;
    10.             else
    11.                 maxHealth = value;
    12.         }
    13.     }
    14.     private int health;
    15.     public int Health {
    16.         get { return health; }
    17.         set {
    18.             health = Mathf.Clamp(0, maxHealth
    19.         }
    20.     }
    21.  
    22.     private Transform target;
    23. }
    24.  
    In this case you don't want to serialize maxHealth and health, as they are private and can be initialized with invalid values (i.e. a manipulated XML or binary file). Instead you only want to serialize the public properties, because they use sanity checks.

    Also you do not desire to serialize the Transform, when you have the player information (i.e. while creating a savegame). So if you try to serialize this class w/o declaring [Serializable] attribute, the serializer will throw out an exception, because the class is not marked to be serialized.

    This prevents that you accidentally try to serialize a class, which was not specifically marked for serialization (i.e. imagine I make a framework/library and I don't want that this class can be serialized, I just leave out the [Serializable] Attribute) and when you do this you usually also look exactly through the class and mark fields you don't want to be serialized with [NonSerialized]).

    Also some serializer (BinarySerializer for example) do also serialize events, which is in 99% of the cases not desired and must be marked with [field:NonSerializedAttribute()]

    Code (csharp):
    1.  
    2. [field:NonSerializedAttribute()]
    3. public event ChangedEventHandler Changed;
    4.  
    It basically prevents you from accidentally doing mistakes. Unity handles the Serializable stuff a bit different, but the explanation is quite necessary to understand the concept why it's required. It's somewhat of an advanced topics and there are enough documentation on the internet for people who really need to serialize stuff into xml, json or binary data.

    Also it's some kind of security feature, so you can't dump classes contents i.e. XML to the disc (though you can get it through reflections, though reflections are limited in Silverlight (=similar to java applets/flash which runs inside a browser)).

    Also before people cry out: This is not C# specific. Attributes are .NET/Mono specific and as thus apply to all languages which compile to CIL (C#, Unity, Boo, IronRuby, IronPyton etc.)

    @Diviner:
    The fields do not have to be public in general to be serialized, according to MSDN. That's just the case for Unity Inspector visibility (which you can override with the [SerializeField] tag).

    I.e. a Binary Serializer will by default also serialize private fields to (unless marked [NonSerializable]) while Xml serialize only serialize public fields
     
    Last edited: Apr 23, 2012
  14. c-Row

    c-Row

    Joined:
    Nov 10, 2009
    Posts:
    847
    I still don't quite get what it's good for and when to or not to use it, but that's not your fault. ;) Guess I should pick up a good book at some point and just code away for now.
     
  15. Ricks

    Ricks

    Joined:
    Jun 17, 2010
    Posts:
    650
    Because some people mentioned that the language could be a reason why a game engine is chosen:

    Actually in my case this has happened. Couple of years ago I was evaluating game engines, and coming from a Java/Python background I avoided everything with a C-language in it. I had the impression anything C-related was somehow complicated and diffcult. Despite I went with Neoaxis Engine (pure C#) first, because the graphical features of Neoaxis were much more convincing. After some testing I found out that no manual existed in Neoaxis Engine and all you got was the API, nothing else. This was really digusting to start with.
    I then went over to Unity being happy that I didn't need to touch C# ever again (this bad impression of the C# language was intensified by my NA experience (which actually was not the cause of C# itself, but a result of the missing manuals).
    In Unity I also felt comfortable with programming languages like Java or Python, fitting to my background. Thanks to the manuals I could start easily in US and get projects done.

    The bad sides added up though: I stumbled across many issues using US, for example generics, dynamic type and variable initialization - leading to lots of unexplainable errors in my game. It was very time consuming to find the cause for them, because the compiler showed everything as correct! This definitely is NOT user friendly. Even though US actually worked correctly - I produced lots of these errors, leading to gameplay flaws and bad habits.
    Later on I needed different kinds of lists in Unity and was suddenly forced to use some C# libraries. I thought: "what the hack? Why do I suddenly need C# libs?". I expected US to be complete enough to be a language that lives on its own - but this isn't the case. The more I dug in, the messier it got. Even in the irc-channel I was told these errors happens because I used US and it didn't happen in C#. The icing on the cake was that you couldn't use lots of 3rd party scripts because most of them were in C#. Also not beginner friendly if the community is divided right at the beginning.

    On a new project I chose to take the step to C# (being fed up with US) - and found out there really isn't so much difference to US. Anyone using US will adapt to this language within a day. It's almost a fluid passage, because as you are writing code almost the same like in US, with the difference you need to open once in a while the Unity API to see how the syntax is for the specific method in C#. That's all. Besides it's easier to find, how logic and programming is done in this language since it's an industry standard. I am by no means a fan of C#, but it's definitely the better choice.

    Still... if someone asks me if I had chosen Unity at my time of evaluation if it hadn't offered anything else than C# - I wouldn't know. If I had the experience from now I would immediately say "yes", but you know - as a beginner you'll always look for the product which is easiest adaptable. The conclusion: US only looks beginner friendly on the first look - but eventually results in much more frustration than using C#.
     
  16. Diviner

    Diviner

    Joined:
    May 8, 2010
    Posts:
    677
    Never said they have to.
     
  17. alexzzzz

    alexzzzz

    Joined:
    Nov 20, 2010
    Posts:
    1,447
    I've just made it for myself:

    \Unity\Editor\Data\Resources\ScriptTemplates\81-C# Script-NewBehaviourScript.cs.txt

    Code (csharp):
    1. using UnityEngine;
    2. using System;
    3. using System.Collections.Generic;
    4. using System.Linq;
    5.  
    6. public class #SCRIPTNAME# : MonoBehaviour
    7. {
    8.  
    9. }
     
  18. jonjonjonj

    jonjonjonj

    Joined:
    Jul 8, 2012
    Posts:
    1
    i couldnt agree more with dropping unity script and boo. i personally think that unity supporting 3 languages is a negative not a positive. it would be nice to have all code samples, examples, tutorials and documentation in 1 language. not to mention that c# has msdn and tons of other resources and unity javascript doesnt exist outside of unity. with only 1 language all of unitys resources can go into making c# better.

    i keep hearing all this nonsense about how javascript is "easier to learn" then c#. whats easier about it? you dont have to write 'class MyClass : MonoBehaviour' or that it can be dynamic typed? the last thing someone who is new and learning a language should be doing is using a dynamic typed language which in the long run will only cause annoying/hard to find bugs because of typos. im sorry but javascript IS NOT any easier to learn then c# and i would argue its actually harder. whenever i try using unity script i want to pull my hair out because the lack of intellisense and having to use monodevelop instead of VS. not to mention unity script syntax is so ugly compared to c# code.
     
  19. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    Opinion, and I disagree, it's a positive.

    Wrong, C# can only ever be C#, they can't make it "better" in any way. (That's kind of the point, in fact.) As opposed to Unityscript, which they have control over since it's their invention.

    Opinion, and I disagree. I've already explained a number of things that are easier. You can ignore them, but that doesn't make them go away. Besides, the default script includes #pragma strict, which removes dynamic typing, so that argument doesn't work either. I'm not sure you actually know Unityscript very well.

    Opinion, and not one I agree with, quite the opposite: I say C# is ugly and worse than Unityscript. Since all you have is opinion, and plenty of people prefer not to use C#, you've made no argument whatsoever that there's any logical reason for dropping the other languages. If you prefer C#, that's fine, go ahead and use it. Don't try to make things worse for people who disagree with you though.

    --Eric
     
  20. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,830
    They could improve the API, develop snippets etc.

    I distinctly remember countering most of them, and quite a few I did make 'go away'.
     
  21. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    Yeah, they could Unity even turn into Visual Studio. But why should they? Unity is a game engine. Not a C# ide.

    And i distinctly remember that i recountered them, and made your arguments go away. Funny thing such a memory ...

    Eric nailed it down, it`s all a thing of opinion. What is a strong point for the one user is a weak point for another user. When you are happy with C#, then go use it, and best wishes.

    But please don`t even try to decide for me. For me it doesn`t matter what is better for YOU. The only thing that matters for me is what is better for ME. With Unityscript, C# and BOO we have the freedom of choice. Everybody can decide by himself what he wants to use. All three languages have their pros and cons. For me it is most important to have an easy to use language. Unityscript is easy to use for me. C# is not easy to use for me.
     
  22. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    Improving the Unity API isn't related to C#. What does "develop snippets" mean? For the docs? They already do that in Unityscript, and they have an automated tool to convert to C# and Boo, so there's no gain there.

    No, you really didn't. Sorry.

    --Eric
     
  23. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,830
    They could improve the API, in particularly by using C# idioms and capabilities that US does not have,

    Right now we have US 'snippets' but we do not have the equivalent in C# - this is well covered in the thread.

    That is an opinion on something that could actually be verified or refuted with some effort. Unfortunately we can't seem to find anyone seriously willing to present US's case.
     
    Last edited: Jul 8, 2012
  24. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    This has changed meanwhile. Every example snippet is available in JS, C# and BOO now. I wonder since when i have overlooked this ...

    And YAY, i can upload images again :D
     

    Attached Files:

  25. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    I'll just keep banging out games in a convoluted mix of c#, js and Boo (yes there's some Boo in it for laughs as of today after reading this thread). I do it because can, not because I can't.

    Plus I'll find it amusing posting my sales reports and grandly, in bold, saying "Proudly made in Boo, JS and... C# !!!" :D

    Never underestimate the value of personal preference. Otherwise life would surely be boring and creativity stifled.
     
  26. Demigiant

    Demigiant

    Joined:
    Jan 27, 2011
    Posts:
    3,239
    Not true for everything. Especially for Editor documentation, some examples are US only (without that nice little dropbox). This doesn't mean I want US or Boo out: I'm just saying :p
     
  27. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    Hm, i haven`t found a JS only example after a quick search. So i have thougth it has changed for everyhing now.

    I really wish there would be a way to comment the manual.
     
  28. Demigiant

    Demigiant

    Joined:
    Jan 27, 2011
    Posts:
    3,239
    Totally agree. Being able to comment the docs would be great. Also, having more decent docs (especially for the Editor) would be great too :p About the JS only examples, almost every (or maybe totally every - I didn't check thoroughly) Editor class has JS only examples.
     
  29. alexzzzz

    alexzzzz

    Joined:
    Nov 20, 2010
    Posts:
    1,447
    A year, maybe even more.
     
  30. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    A year has passed and some docs still aren't up to scratch? They should do what blitz did once, have a submission box for missing examples and fixes :) then when the docs team do a pass they can see all items which are flagged with a reply and choose to incorporate it if it looks well-written, saving them time and improving the docs as well.

    Could turn out to be the best docs ever written, or a pile of garbage though.
     
  31. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,830
  32. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    What is your point here my friend?
     
  33. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,830
    Read the link/thread.
     
  34. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    I have. And i can absolutely not see what your linked posting has to do with my quoted text. That`s why i ask what your point is with this Fail attitude. Being rude and arrogant again? I already know that. You don`t need to prove it again all the time.
     
  35. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,830
    I made the point that we do not have C# snippets, you then quoted this and claimed otherwise. I then referred you to a detailed explanation of what I'm talking about. Then I got accused of being 'rude and arrogant'.

    What exactly is the problem?
     
  36. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    The "problem" is that putting a /FAIL behind a quote and throw in a link as an answer to a quote IS rude and arrogant :)

    And i still think that your linked posting has nothing to do with the quoted text. It`s just your usual JS bashing and C# praising.
     
  37. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,830
    'Rude and arrogant'?

    I didn't quote someone talking about one issue, then completely and utterly fail to comprehend what they were talking about in response. Then, when corrected, I didn't feign ignorance and start calling them names.

    If you want to talk about a completely separate issue that's fine, just don't bring me into it m'kay?
     
  38. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    Actually npsf3000, you come across like a complete dick 90% of the time on the forums. That's OK coming from me because I am a dick 99% of the time. Thought I'd share though.
     
  39. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    Yes, i say it again, putting a /fail tag behind a quote and put a pure link to something that has nothing to do with the quote arrives as rude and arrogant at my end. Rude because it is everything but friendly to call a posting a fail. And arrogant because adding a link instead of an answer means you don`t even bother to give a useful answer at all. This is not calling you names by the way. And i did correct you, not the other way around. You just linked to a big wall of text, which has nothing to do with the issue you have quoted from me.

    Anyways. You don`t even see where you are wrong. Every further word will just lead to more trouble from what i can see. So think what you want.

    On with something completely different ...
     
  40. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,830
    Meh. I've been a dick and I've been a calm voice of reason. I've been a troll and I've been a helpful contributory. Sometimes I change, sometimes the views of those around me change.

    In short, such is life.


    @Aruderan, just for you:




    If I'm a dick, don't quote me out of context, m'kay?
     
  41. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    So about what code snippets are you talking here then? I thought and think that you talk about the code snippets in the scripting reference. Which is not quoted out of context.

    EDIT, and i don`t call you a dick neither.
     
    Last edited: Jul 9, 2012
  42. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,830
    Well, I would suggest reading this thread or that post I gave you that specifically covered this issue... but we already know what the response to that has been don't we?

    So I'll just spam the thread repeating myself:

     
  43. nonaxanon

    nonaxanon

    Joined:
    Jan 20, 2012
    Posts:
    44
    im a newbie, and ive seen so many examples on here from boo to js to c#, i dont think anyone has a real problem with those languages being around, if you want to learn pick one and learn, its a matter of own taste i think, i use c# and js, i dont use boo for anything, but whats the point in taking out all those languages, its better for people to have other alternatives to try
     
  44. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    No. We just know that you very easily go the rude and arrogant route. And you repeat it here.

    I should`ve been quiet as i wanted to. Think what you want. On with something completely different.
     
  45. Khyrid

    Khyrid

    Joined:
    Oct 8, 2010
    Posts:
    1,790
    How things are != How things ought to be and it's also unrealistic to think you can always make it so with blunt sweeping actions. There is a substantial user base for US and a few random Boo users that would be alienated if Unity made it all C#. I myself use US, however I may learn C# in the future.

    It has been said that US is better for beginners and some has disputed this claim. Allow me to settle this disagreement now, US is easier for beginners. Not because there is necessarily anything inherently easier about the syntax, I don't know, but because there are more tutorials for it for beginners.

    Having said that, it would be a simple matter of making C# clones of all the tutorials to rectify that if C# was to become the only language. It would be a risky move by Unity because they would have to force everyone to switch and it would cause an uproar.

    If you wanted to make C# the only language the best way to do it is to make more people use it so Unity doesn't feel any need to support JS or Boo anymore, even of those options are still available, they can focus their support on C#. How do you make everyone use C#? People like the one who made this thread start building C# tutorials and converting official US tutorials over to C#, make C# approachable. If C# is easy for beginners and allows compatibility plus it can be used for stuff outside Unity, people will switch over by themselves without Unity having to force anyone.

    tl:dr; Make C# easy for beginners and US will die on its own.
     
    Last edited: Jul 9, 2012
  46. Demigiant

    Demigiant

    Joined:
    Jan 27, 2011
    Posts:
    3,239
    My two cents too :p

    I agree with what Khyrid said (even if I'm a C# user). Independently of the fact that C# might - or might not - be a harder language than US, a lot of people come to Unity from Flash/ActionScript, or have a prior knowledge of JavaScript. Thus, obviously, US requires less effort.
     
  47. DavidC02

    DavidC02

    Joined:
    Jul 19, 2011
    Posts:
    152
    I hope this never happens. What a terrible idea. Having Javascript in there makes it so much less scary for new comers.
     
  48. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,816
    What exactly makes C# more scary than JavaScript?
    The extra 2 namespace declarations at the top, and the line containing the class definition?

    Please, with intellisense in VS and C# being far superior than anything MonoDevelop and JS has to offer C# is by far IMHO the easier language to learn and develop in. Not to mention its the same identical language of any ''C#' tutorial on the internet you'll find. Type in 'javascript tutorials' into Google and you'll get a lot of confused people because Javascript is actually a different language used for different purposes, Unity doesn't use 'javascript', it uses its own scripting language based on javascript... but now it's getting confusing isn't it?
     
  49. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,649
    This whole suggestion is horrendously fascistic.

    Also:

    Great, so that's an opportunity for someone to write a library that does the same thing but is in C#.

    Alternatively: you could have put the JS library in your Plugins/Standard Assets folder to move it to firstpass compile, or you could have built it as a class library in MonoDevelop and then just dropped the DLL into your project wherever.
     
  50. Demigiant

    Demigiant

    Joined:
    Jan 27, 2011
    Posts:
    3,239
    Actually, no. It's actually quite normal for a software to change its language or focus on a single one, without it being called fascistic. Focusing on three different ones is quite expensive (human-work wise), and it inevitably leads to bugs accumulating and not being fixed because of the three different areas they span.
    While I don't advocate the elimination of US and Boo (or C# and Boo, or whatever, until there's only one), I certainly can understand why some people might get annoyed. I do too. A lot of bugs are still present since years. And Unity docs are not good at all. Probably, if they could focus on a single language, we would all have a better software. That said, I'd love if we could have 3 bugless languages (or at least as bugless as it's possible) and with good documentation. But, objectively, the last years showed it might not be possible - not that I lost my hope, though :p