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

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,649
    Yeah, but not when at least one of those other languages is being heavily used, and not when the single language advocated is deficient in important ways (i.e. not being similar to ActionScript to make it easy for Flash devs to switch over). If C# actually were the best option for everybody, people wouldn't be using UnityScript or Boo.

    I really doubt it. I don't think it's that UT is short on people - it's that they either don't know about the bugs (what bugs in language features are we talking about, anyway? What are the bug IDs?) or they have the wrong attitude towards the way they're working - for example, not integrating docs-writing into their dev process properly, not offering a simple way for the community to contribute content to the manuals, and so on.

    Yeah, this is what I advocate. UT should work on opening up their compilation pipeline to allow us to plug in any CIL compilers - plus, ideally, asset compilation - and then the community can work on adding support for everything from IronPython to F#. They should be opening Unity up to more languages, not restricting it to fewer.
     
  2. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,816
    True. Not ideal though.
     
  3. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,649
    Well, not having the library at all would be even less ideal, right? That's what you'd risk by killing support for JS.
     
  4. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,830
    I'd argue the opposite.

    By killing JS, any/all libraries worth something would have to be ported once, then it's happy days.

    By maintaining JS, it's an ongoing problem because JS is technically a valid support option, regardless of the difficulty it can cause. Remebering that sticking the script in 'Plugins' doesn't always work.
     
  5. J3-Gaming

    J3-Gaming

    Joined:
    Dec 23, 2010
    Posts:
    55
    I agree with getting rid of Boo, can we all agree that none of us use it?
    My personal opinion agrees with you, I love C# and I hate finding javascript tutorials - because I end up manually converting them to C#.

    But in the end, there are still a ton of developers who are used to javascript and will want to continue to use it, or refuse to upgrade their Unity versions (which could then cause people to post tutorials for older versions of unity, without plans to upgrade)
     
  6. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,649
    If JS were not supported then I'm contending that the library (or others like it) wouldn't have been written in the first place. There'd be nothing to port.

    Only as valid as you make it. If the community don't buy JS packages because they're uncomfortable with doing development on top of that, then it doesn't matter whether Unity supports it or not - it becomes a bad business decision to write packages in JS.

    And the reality is that for the vast majority of people, it doesn't matter what language the code is in, because they don't have the requisite knowledge to modify it anyway.

    Anyway, what should and should not be offered on the asset store is a different thing to what Unity should support /at all/. Requiring asset store packages to only use C# would be less horrendous, as it would disrupt fewer people, and it's not that hard to sell your tech outside of the asset store if you need to.

    I would more advocate prebuilding to a DLL, particularly for asset store packages. If you can describe a case where that doesn't work then I'd be interested to hear it.
     
  7. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,649
    I guess one of the things I don't really get is this idea that one can know C# well but be unable to comprehend Javascript. They swapped the order of the type annotations, but other than that, what's so difficult to read about a JS example?
     
  8. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,830
    The question isn't how many *would* have been written but rather how many *will be*.

    The problems of the past aren't the problems of the future, and maybe the solutions differ.

    True. The question then is of efficiencies. There's a cost to unity and a cost to the community from US, is it still worth it?

    C# script relies on US script relies on C# script relied on US script.

    While I've not tried to build DLL's [don't think it would help?] this sort of situation does happen.

    US is pretty easy to read, but I'm a programmer not a reader. Adding even trivial functionality can be difficult because US lacks basic features or hides them away in non-existent documentation. Then add in the various incompatibility due to the passing order...

    Let's just say I often get find or buy smallish scripts to do basic functionality, then spend $100 of my time rewriting them in C# to actually use.
     
    Last edited: Jul 13, 2012
  9. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,649
    Dropping US support from Unity over the next couple of major versions would affect existing packages; you can't ignore the past. Anyone presently maintaining a US package would have to port it to C# (which the market has not demonstrated a clear need for), and I think there will be some developers who don't have the time or interest to do that, so we'd lose some existing packages.

    Yes, sure. But we're not in a position to know the cost to UT. Now that the feature is there, I don't think it costs them very much. The cost to the community is more apparent, but a) we can resolve a lot of that without UT having to do anything, by writing references, tutorials, FAQs, etc, and b) we can make the cost to us clear to UT without calling for US to be axed. There are other solutions, like allowing more community contribution to the official documentation.

    Yes, I've had this myself. Building a DLL solves the problem.

    The documentation is an issue; UT really need to publish a US language spec. But what basic features does it lack?

    Can you explain that? To my understanding, all US is compiled down to CIL, the same as C#, and is reference-bound to exactly the same assemblies as C# is, so function arguments will be exactly the same in each.
     
  10. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    superpig, it doesn`t make any sense to discuss with this C# folks here in this thread anymore. You can`t convince fanatics. No matter what you say, they will always disagree and praise their C# god. They are not interested in arguments and facts.

    You do them even a favour when you still talk to them. This discussion stays on top by that, giving them a platform to provide their abstruse ideas. Best thing is to simply stop responding so that this thread sinks into the forum abyss. That`s where this thread really belongs to.
     
  11. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,816
    So now all those who prefer C# and C# only are 'fanatics' and we are wrong?
    We've always tried to make valid points in this argument. Its posts like this of yours that are useless that deserved to be thrown to the bottom of the internet pile.
     
  12. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    Nope. You can prefer whatever you like. And that`s already the big difference between us two. You don`t want me to prefer what I like.

    When somebody ignores all arguments and facts, and tries to discredit the opponent with all possible and impossible weapons and the dirtiest polemic tricks, when we have some folks that doesn`t want other folks to live in another way than their way, then we can definitely talk about some fanatics. And this is what this whole thread does.

    Honestly, i wouldn`t wonder when i would find some of you guys ringing at my door, wearing a dynamite belt.

    Fact is that Javascript and BOO are valid languages for use with Unity. And fact is that you have absolutely no loss compared to C#. Because all three languages provides the same engine functionality, with the same speed. Fact is that you and others tries to remove those valid languages from Unity for the sake to praise your C# god. That`s what this thread is for. With all weapons. Against all arguments and facts. And with the dirtiest polemic tricks.

    Like this again for example. And this thread is full of stuff like this. F*** for arguments, let`s kick the argument teller into the balls instead until it is quiet:

    That`s how your arguments look like. That`s your "valid points".

    And i think now i have really said what i wanted to say to this thread. Over and out.
     
  13. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,816
    Good. Because looking back at this discussion you've brought little value to it.. except making attacks and other derogatory statements, and not contributing to the discussion in a meaningful manner.

    Go answer your door bell, maybe your pizza delivery has arrived.
     
  14. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    And another kick in the balls. Thanks for proving again ;)
     
    Last edited: Jul 13, 2012
  15. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,830
    Not to be rude, but are you not describing yourself?

    I have used US and C#. I have participated in the community and helped members with scripting. I've helped 'tutor' people on the basics. I've used and do use most of the language features described in this thread. I back my arguments up with real world experience, and example code snippets.

    You on the other hand have many posts claiming to be a victim and that people are out to 'bash you', religious fanaticism so on and so forth. You're main tactic appears to be to derail the thread, rather than provide meaningful debate.

    Moving on...

    Whoa, no one said anything about ignoring the past, but recognizing the past is not the future. While I do recognise that we might lose some packages... if you're not willing to rewrite your package over the next 2-3 years to be C# based [fairly easy to do] then I'd be surprised it'll work at all - given how U3D has changed in past versions.

    My biggest two complaints would have to be events and generics. Oh and VS support [even if that's technically not the language's fault].

    Not exactly missing, but hard to do would be structs and properties where there is a way of doing it, but trying to find out what they way is is/was hard from previous experiences.

    Hell, I helped someone debug a parseInt problem recently - in the end I had to go to the US source code to find the problem. Even the basic functionality it does have differed from both the JS and MS JS docs I could find on it.

    The standard - we build this as two separate DLL's so they cannot circular referance rubbish. Imagine if in C# you could not do this:

    Code (csharp):
    1.  
    2. class A{
    3. B parameter;
    4. }
    5.  
    6. class B{
    7. A parameter;
    8. }
    But because one is US and one is C# it no work.

    If you can do some magic dll compiling in mono I'd love to see a tutorial, because I've not seen this covered as of yet.
     
    Last edited: Jul 14, 2012
  16. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    Nice, even more kicks in the balls. Thanks man :)
     
    Last edited: Jul 14, 2012
  17. Aguy

    Aguy

    Joined:
    May 11, 2012
    Posts:
    317
    So you want them to cut out languages that you don't use but others do...

    This make more sense than anything.
     
  18. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,649
    Generics are supported. For example:

    Code (csharp):
    1.  
    2. var myComponent : MyComponent = someObject.GetComponent.<MyComponent>();
    3.  
    It's not the cleanest syntax in the world, but that's true for a lot of US.

    The UnityVS guys are bringing this. TBH I suspect VS support wouldn't be such an issue were MonoDevelop not so godawful.

    Yes, this is the kind of thing that UT really need to provide a language spec for. As a community, there's nothing stopping us from compiling this kind of thing into the Unify Community wiki, though.

    Mm. Circular dependencies are usually indicative of poor design, though. You tend not to need concrete type references going both ways. Apply the DIP and the code becomes:

    Code (csharp):
    1.  
    2. interface IB { }
    3.  
    4. class A
    5. {
    6.   IB field;
    7. }
    8.  
    9. class B : IB
    10. {
    11.   A field;
    12. }
    13.  
    'IB' and 'A' can now be in the firstpass assembly while 'B' is in the regular one.

    I think I just created a US Class Library project in MonoDevelop, added the US files to it, and compiled. I can write a quick blog post on it or something if you really want, though.
     
  19. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,830
    The ability to consume generics created elsewhere is available, but not the ability to create generics.

    http://forum.unity3d.com/threads/13...nal-in-Unity-5?p=891231&viewfull=1#post891231

    If there was a suitable alternative then it wouldn't be an issue. I like the looks of unityvs but it's not done yet [AFAIK] and I strongly suspect it'll be VS pro only.

    True. However as one community member I'll put my time and effort into C# advocacy - there's a better payoff :p

    Quick question... how does the Unity API work? The GO has a reference to the transform... and the transform has a reference to the GO.

    While I could probably figure it out should it be necessary I suspect it'd be quite a useful resource for the community.
     
  20. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,649
    Ah. Yeah, OK.

    Actually, no, it doesn't: the transform derives from Component, and Component has a reference to the GO. Component is the playing the role of 'IB' in my earlier code example.

    Anyway, so what? There are plenty of poorly designed aspect of the Unity API. Just because Unity does something doesn't mean it's a good idea. Otherwise this entire thread would be trivially refuted :p

    Alright, I'll see what I can do.
     
  21. gioworks

    gioworks

    Joined:
    Oct 12, 2011
    Posts:
    138
    Dont delete JS, it is so easy for begginers and it should stay in unity forever.
     
  22. keithsoulasa

    keithsoulasa

    Joined:
    Feb 15, 2012
    Posts:
    2,126
    I wouldn't mind getting rid of Boo very slowly, its just not used all that much any more .
    like take a poll when activating Unity on what langage you use , and if Boo gets less then 5% get rid of it

    Don't turn into an elietist UDK where it takes a computer science degree to even get started .
     
  23. Aguy

    Aguy

    Joined:
    May 11, 2012
    Posts:
    317
    A poll? Like 1% of the forum will answer.

    Elitist? Yet you say they should get rid of Boo because not everyone uses it. Well some people do. Some people learned Python vs other languages.

    That's like starting a thread and saying remove C#.

    Unityscript is Unityscript and there are people who use that too.

    So many other things people could be using their time on then trying to get rid of languages that other people use.

    Example: http://forum.unity3d.com/threads/72458-Official-Boo-Scripting-Resource-Thread/page4
     
    Last edited: Jul 19, 2012
  24. zipper

    zipper

    Joined:
    Jun 12, 2011
    Posts:
    89
    Some more powerful aspects of C# programming that US users may not be aware of are Extension Methods:
    http://msdn.microsoft.com/en-us/library/bb383977.aspx

    The most well known being Linq:
    http://msdn.microsoft.com/en-us/library/bb397926.aspx

    Here is free tool to play around with Linq called LinqPad:
    http://www.linqpad.net/

    With linq i can read in an entire xml document with the following code:

    Code (csharp):
    1.  
    2. // This code uses System.Xml.Linq
    3.  
    4. // Note: You will need drag and drop
    5. // <Unity Install Location>\Editor\Data\Mono\lib\mono\2.0\System.Xml.Linq.dll
    6. // directly into your project for this to work
    7.  
    8. // This is a code snipet from an xml reader importing
    9. // an [URL="http://www.ogre3d.org/"]Orgre 3D mesh object[/URL].
    10. void ReadXmlFile(string fileName)
    11. {
    12.         XElement xmlDoc = XElement.Load(Application.streamingAssetsPath + @"\" + fileName);
    13.  
    14.         var verticesQuery =
    15.             from positions in xmlDoc.Descendants("position")
    16.             select positions;
    17.  
    18.         foreach (var vertex in verticesQuery)
    19.         {
    20.             var x = (float)vertex.Attribute("x");
    21.             var y = (float)vertex.Attribute("y");
    22.             var z = (float)vertex.Attribute("z");
    23.  
    24.             _vertices.Add( new Vector3(x, y, z) );
    25.         }
    26.  
    27.         var normalsQuery =
    28.             from normals in xmlDoc.Descendants("normal")
    29.             select normals;
    30.  
    31.         foreach (var normal in normalsQuery)
    32.         {
    33.             var x = (float)normal.Attribute("x");
    34.             var y = (float)normal.Attribute("y");
    35.             var z = (float)normal.Attribute("z");
    36.  
    37.             _normals.Add( new Vector3(x, y, z) );
    38.         }
    39. }
    40.  
    As you can see, the extensions methods provided by Linq make the queries extremely easy and concise.

    You can use extension methods to make Unity classes behave how you think they should behave. Prime31 has some excellent examples of how to extend the AudioSource class to playclips, play a random clip from an array of clips and so on:
    http://www.youtube.com/watch?v=va556bGnXIg

    I highly recommend investigating these features of the language even if you are not a fan of C#.

    They are, like anything else, a set of tools that will help you be more productive and allow you to "mold" the current Unity API to your bidding :)

    Best,
    zipper
     
    Last edited: Aug 8, 2012
  25. nuverian

    nuverian

    Joined:
    Oct 3, 2011
    Posts:
    2,087
    Javascript *MUST* stay. Unity is a game designer friendly game engine as well. Having JS here empowers the game designer and lifts the burden of the core programmers. It also empowers effects and technical artists in general. Every major game engine has and should have a scripting language. Period.
    Not to sound aggresive, but bacause you know C#, doesn't make the rest languanges obsolete. By that logic, every javascripter should also say remove C#, but that would as well be a completely wrong statement to make or desire to have. Each have a different use in production and the only right statement would be to make them work better together.

    my 10 cents
     
  26. Demigiant

    Demigiant

    Joined:
    Jan 27, 2011
    Posts:
    3,239
    +1

    I suppose almost everyone wanting to remove US is mostly pissed by the fact that Unity's languages don't work well together, which is not an issue when working with a team (since a single language will be chosen and used by all members), but a big issue when developing (or using) plugins for others.
     
  27. Tope

    Tope

    Joined:
    Mar 28, 2012
    Posts:
    23
    Seriosly, before open this topic I though it was a joke...


    Let's see this on the other side... why dont why remove C instead?

    One of the most important things in unity is that you have not 1 not 2 but 3, yes 3 differnt languages... and you can chose the one you want...

    I belive that if unity remove javascript lot's of people would just quick from unity and start using other game engines... and least I would...
     
  28. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    Well you can't get rid of boo without getting rid of js, because the two are forever entwined.
     
  29. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    Not encountered many if any problems myself but I can see a bigger issue - assets from the asset store.
     
  30. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,816
    In a nutshell yes, which is what initially caused the creation of this beastly thread.

    The other main point was it would be nice to have one language that all tutorials and libraries were in to make the transition/learning easier. But all the languages are here to stay.. just wish they worked transparently together.
     
  31. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,830
    They did.

    Unity does not officially support:

    • C
    • C++
    • Lua
    • Java
    • Erlang
    • F#
    • BrainF*ck
    • PHP
    • Many, Many More.

    as scripting languages.
     
  32. erazor

    erazor

    Joined:
    Jan 24, 2011
    Posts:
    8
    My name is Oliver and I endorse this message (eh thread).
     
  33. guavaman

    guavaman

    Joined:
    Nov 20, 2009
    Posts:
    5,605
    I've been working with UnityScript for over 2 years now and I've come to seriously regret my decision to use it. I was lured in by the readable syntax and scared away by all the people who said C# was a lot more complicated, harder to read, and requires a ton of casting and such. UnityScript is supposedly great for beginners. That's actually 100% opposite from the truth IMO. People think its easy for beginners, but it really only makes things 100x harder in the long run when you want to do more than just pop a few small scripts on game objects. Partly because it teaches you to do things the wrong way and lets a lot of bad coding practice slide by without warning, also because it obfuscates many important concepts in .NET thereby never letting you learn how things actually work (ex: passing objects by reference/value), because simply it does not allow you to use many of the extremely useful features of the .Net/mono framework (custom indexers, custom equality comparisons, ref/out, abstract classes/methods, nested classes, namespaces, etc.), but mainly because it's just not well supported by the company that made it. UnityScript is presented as a fully-functioning alternative to C#, but Unity is unwilling to support the language to the level required for use in serious projects. The primary example of this is MonoDevelop which simply does not work correctly when using UnityScript, especially autocomplete, and certainly not in a large project (I have 160 script files in mine and have long since disabled autocomplete). Another example of this is the utter and complete lack of documentation on UnityScript which is broken and scattered in a dozen places on wikis, forums, release notes, etc.

    The idea that UnityScript is better for newbies is a ruse and a trap. If you ever intend to expand your game beyond the scope of a few basic tutorials, you're in for more headaches than you can imagine. C# is NOT more complicated. In fact, it's less complicated because it doesn't allow you to get away with not understanding how things work and paint yourself into a corner. It warns you about all kinds of little tricky things US just overlooks which can lead to hard-to-track-down bugs. It's NOT harder to read once you're used to it. (The casting object to type stuff scared me back then, but it makes sense and is not hard at all.) It has FAR FAR FAR better tools available for it (Visual Studio) that actually work and will allow you to get actual work done in 1/4 of the time instead of fumbling around with broken, half-implementations. It is also extremely well documented on MSDN. And let's not forget, once you learn C# you can also write tools and other things outside of Unity to help process and automate things. Plus, if you learn C#, you'll have learned a language and that will be useful beyond just Unity and would be far better on a resume should you want to work in the industry.

    After struggling with the limitations of UnityScript for too long, I finally decided to convert my entire project over to C# and am in the midst of doing that. I thought I was being very careful with things like using #pragma strict and such, but I'm finding as I go through my code that I did qute a lot more things poorly than I thought and US just let me get away with it. I hope to get this done soon and never have to look back at US or MonoDevelop again.
     
    Last edited: Sep 11, 2012
  34. pivotraze

    pivotraze

    Joined:
    Feb 4, 2012
    Posts:
    593
    As I read this thread (and I'm not done), I could only think of this.

    DO NOT remove Boo. That's why I use Unity. If it was removed, I'd leave Unity purely due to the fact they removed a language that clicks with me, since I came from a background of 3+ years with Python. That is why I chose Unity. If Boo is gone, I'm gone.

    What engine would I go to? Out of spite, UDK. I know UDK pretty well, I know UnrealScript relatively well, and (for me), I find it easy to use. But I like Unity more BECAUSE of Boo.

    People don't understand that Boo can do practically EVERYTHING C# can, with a cleaner syntax. I have not found one thing I can't do with Boo, that C# can*. It doesn't introduce a bad API, or anything. It introduces a design paradigm. Clean syntax, ease of use. Almost anything I've seen written in C#, I've written in fewer lines in Boo.

    *note, I don't care too much about mobile development. I've read Boo CAN do mobile development, but I've never done it since I don't care about it.

    Hate to say it, but you're wrong. I'm a hardcore Boo programmer when it comes to Unity. I use Python outside of Unity. I hate C# because of it's syntax styling, and UnityScript because of it's limitations, but I would never champion the saying of "Remove C# and US! Why do we use them when we have Boo?!" Why? Because ALL languages have their uses. UnityScript has ease of use, but I wouldn't recommend it because you can't go too far with it. C# is a powerful language, equal to Boo, and is where you should go if you want to have a similar syntax, or have used it previously. Boo is where you should go if you want a clean, simple syntax that provides equal power of C#, with more (such as duck typing).
     
    Last edited: Sep 12, 2012
  35. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    You're all moaning too much and not getting enough games done. The C# and unity js integration is possibly like 30 mins taken up of your 6 months + development time.

    I don't know. I have done plenty of games in js from start to finish without any problems. Even a really complicated physics music app. I didn't have any language issues at all.

    Perhaps you're a natural C# programmer and merely prefer it or something, which is cool too. But what you said, is a matter of personal opinion, not fact, because I've got proof to the contrary with 70,000 lines of music app (probably more by now) selling and saying "it works fine".
     
    Last edited: Sep 12, 2012
  36. guavaman

    guavaman

    Joined:
    Nov 20, 2009
    Posts:
    5,605
    Then I have to assume you don't use an IDE because MonoDevelop is completely broken when using UnityScript. That's a huge language issue because no other full IDEs support US. I've created ALL of the 130,000 lines of code in my project in UnityScript in UniSciTE, Notepad 2, Notepad++, UnityDevelop, and MonoDevelop. NONE of them provide a smooth working environment. I can't imagine how much time I've wasted in my project searching to find and retyping every single variable name, digging through the Unity docs because I couldn't remember the specific name of a method because Autocomplete sucked, or waiting 5-10 seconds for autocomplete to show up just to find out that nothing relevant popped up, etc. All that time would have been spent "getting games done". No Hippo, I have very good reason to "whine" or in other words state my opinion based on my experience. And I do it in hopes it will help someone out there to stay out of the situations I've gotten myself into because I believed the hype that UnityScript was better for beginners.

    I am not a natural C# programmer by any means. Like I said, I've been using UnityScript for over 2 years and learned everything about Unity on it. I am only starting to switch to C# now. I have no prior C# experience except for a few helper tools I coded in the last couple of months and after using Visual Studio for those I realized just how stupid a workflow I had with MD and how amazingly convenient and productivity increasing it was to have all the powerful features of a real IDE at my disposal. I definitely prefer US syntax, I do like not having to cast objects, but I absolutely cannot stand the horrendous, time-wasting workflow.

    "Works fine" is a more of a matter of pure opinion than anything I said. I gave very specific reasons as to why C# is a better language to learn with advantages of it and disadvantages of US. You can disagree with those points if you prefer coding without assistance in notepad, or you dislike having all the features of .NET at your disposal, or you like going through code with a fine-tooth comb looking for mistakes US let you get away with, you like using Google instead of a language documentation, or you like having everything abstracted and never understanding how the code actually works then things break and you have to go to the forum to get someone to explain why it doesn't work the way you thought. I gave very valid points as to why US does not "work fine" and is a poor choice for beginners, including tools and documentation which have a direct impact on productivity. As a newbie, you have no choice but to waste countless hours tinkering and scouring the forums trying to figure out what features US supports and what it doesn't when you need them and what syntax to use, and only after you've done that over months can you reach the point of our experience where we know it well enough to get complex things done. I COULD release my game in UnityScript and it would "work fine" in the end, but there's a phrase that goes like "work smarter, not harder". Getting to that goal is a whole dang lot harder with US than C#. "Harder" is a matter of opinion, but it's also my opinion that building a house with a hand saw and a hammer is a whole lot harder than with power tools.
     
    Last edited: Sep 12, 2012
  37. guavaman

    guavaman

    Joined:
    Nov 20, 2009
    Posts:
    5,605
    I thought I had to update anyone reading my posts above as to a brand new finding of mine regarding UnityScript:

    C# compiles 4X FASTER than UnityScript!

    For a long, long time I've been struggling with incredibly slow compile times in my project. It got so bad that every time I made a tiny change I had to wait a full 15 seconds for Unity to compile my project. This made it unbearably slow to do any kind of debugging. If I made 200 tiny code changes per day, I'd be wasting nearly an hour of time waiting for compiles. I said enough is enough and started researching ways to improve my compile times as chronicled here and here. I spent several weeks doing a lot of testing and research and eventually converted my project to a bunch of external DLLs which would allow me to compile just one part of my project at a time thereby reducing my compile times dramatically. I eventually got it done, but it made for a somewhat cumbersome setup when making changes to anything. Still, it was fast. After doing that, I decided to convert my whole project to C# because I grew tired of dealing with MonoDevelop's issues. I just finished that conversion last night. This morning, I decided to test something I was curious about. What if I just moved all my loose .cs scripts back into a Unity project and let it compile those? I was floored by the result. What took 15 seconds to compile using UnityScripts took only 3.5 seconds using C# scripts! Even without going to all the trouble of breaking my project into DLLs, my compile times were suddenly bearable!

    Going back to my my 29-project externally-compiled DLL setup, C# re-compiles the whole solution in just 3.5 seconds (Visual Studio or MonoDevelop) where UnityScript takes a whopping 44 seconds. In this kind of setup, C# compiles 12.5X faster than UnityScript.

    Even if none of the reasons I gave above are enough to convince you to use C# over US, if you are creating a fairly large game this is reason enough.
     
    Last edited: Sep 17, 2012
  38. Demigiant

    Demigiant

    Joined:
    Jan 27, 2011
    Posts:
    3,239
    Wow, discussion apart, this is a really interesting discovery. I would be curious to know how Boo compile times compare (I'm definitely not against other languages - and actually find Boo very fascinating - this is just pure curiosity).
     
  39. pivotraze

    pivotraze

    Joined:
    Feb 4, 2012
    Posts:
    593
    For my compiles, I usually only have to wait a second or two until I can start up the game. I rarely notice it. I haven't done very many large coding projects, so I would gladly convert a large C#/US file to compare the times. :)
     
  40. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,830
    Don't stress the LOC too much Hippo... or some of us might start asking if a C# version would have been smaller :p
     
  41. guavaman

    guavaman

    Joined:
    Nov 20, 2009
    Posts:
    5,605
    For kicks I think it would be fun to make a benchmark of sorts to compare the language compile times. I would say it needs to have 50-100 scripts in it, mostly MonoBehaviour based to simulate typical usage. Each should have a number of fields and methods. It would probably be fine to just clone one script 100 times just incrementing the names/class name so you'd only have to do the language conversion once.
     
  42. pivotraze

    pivotraze

    Joined:
    Feb 4, 2012
    Posts:
    593
    If someone writes a script, I'll translate it. Would we take use of language specific features if they apply, or no?
     
  43. guavaman

    guavaman

    Joined:
    Nov 20, 2009
    Posts:
    5,605
    I wasn't planning on doing anything big, just an informal benchmark (not to spend too much time), which I did. Mine was very simplistic. I just created 50 scripts, each with 20 fields of various types and 60 very simple repeating methods. I translated it to all 3 languages, all identical, no warnings.

    Average of 4 tests:
    US: 5.665 s
    Boo : 5.5375 s
    C#: 2.4275 s

    Interestingly, every time I timed US it was slightly slower than Boo, but very close. I even ran all the sequences 3 times, but there was always a tiny lead for Boo over US. I guess this makes sense as US is based on Boo, so you have the extra step of translating the US to Boo at some level.

    So in this ultra simplistic test C# is only 2.33x faster than US and 2.28x faster than Boo. This isn't really real-world usage like my other test where i got 4x - 12.5x, but it would take me way to long to convert my whole project to Boo. :p

    It's probably not an issue for very small projects, but when your game starts getting bigger and bigger, you defeintely notice the speed difference.
     
    Last edited: Sep 17, 2012
  44. pivotraze

    pivotraze

    Joined:
    Feb 4, 2012
    Posts:
    593
    Hmm... that was very interesting. But IMHO, readability > compile times. I feel that Boo is much more readable than C# or US.
     
  45. arkon

    arkon

    Joined:
    Jun 27, 2011
    Posts:
    1,122
    +1 for this. When I started out with Unity, the fact that scripts, examples, tutorials and even documentation was in multiple languages and not always in C# (the language I'd chosen to use) was a right royal pain in the ass. The only good to come out of it was I learnt to convert JS stuff to C# but seriously what a waste of time.
     
  46. alvivar

    alvivar

    Joined:
    Aug 7, 2012
    Posts:
    16
    This is a really scary wish: "Make JS and Boo deprecated in Unity 4. And non-functional in Unity 5" is an awful thing. This should be replaced with "Make better examples and tutorials for JS, Boo and C#".

    There should be always more options, not less, if you don't like Boo or UnityScript don't use it! Use C#! That's all! Don't destroy something that isn't causing problems because you don't like!

    All this remind me how big is the Python community and the JavaScript community. In fact, as a user of Python for several years it was really awesome when I discover that Unity supports Boo! That was great and that help me to choose Unity. Because Boo/Python have this readability thing that I love.

    JavaScript if growing really fast with all the push for Html5. Unity really want to miss all those potential users?

    When you choose a technology to work with, one of the most important things is to enjoy the technology. Unity is an engine for indies, for small studios, for big studios, it's free, it's for everyone! This is the reason why they should keep Boo and JS as an option. Because everyone is a big word and we all enjoy different things.
     
    Last edited: Sep 25, 2012
  47. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,830
    This premises is flawed - more options != better.

    It's obviously causing problems or this thread would never have been created.
     
  48. guavaman

    guavaman

    Joined:
    Nov 20, 2009
    Posts:
    5,605
    I believe UnityScript has its place and was a fun language to use until I kept hitting brick walls in my development because of it and switched to C#, but I really want to see Unity support the language MUCH MUCH better if they're going to have it. There are a lot of oversights on Unity's part, most obvious of which are the lack of language documentation and the horrendously broken MonoDevelop IDE that functions far more poorly and has fewer features* for their own language than for C# which is kind of baffling. Don't make US users feel like they've gotten the short end of the stick all the time. My attitude is if you ain't gonna support it, why have it at all? I don't want them to get rid of it (and I'm sure they won't) -- I want them to commit to it by improving it, fully supporting it, and making it a complete language.

    * In US: MD's autocomplete is attrocious (esp on a big project), no error underlining, you cannot export DLLs without a great deal of effort by modifying the .unityproj files manually and even then the DLL's come out as .NET 4.0 instead of 2.0 because it completely ignores the compile target so you get errors and have to modify game code to accomodate the differences, you cannot disable warnings by id# so you constantly get bogus warnings with every script file about namespaces not being used, etc, etc, all of which work great in C# (except autocomplete is still buggy, just not as bad). With no other real alternative IDE's (on Windows anyway) you just feel totally stuck.
     
    Last edited: Sep 25, 2012
  49. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,816
    True for monodevelop, not true for Visual Studio, which is awesome. Just clearing that up :D
     
  50. guavaman

    guavaman

    Joined:
    Nov 20, 2009
    Posts:
    5,605
    Very true. Now that I'm on C# I'll never be touching the accursed MonoDevelop again... I hope. The difference is not even funny.