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

    Swearsoft

    Joined:
    Mar 19, 2009
    Posts:
    1,632
    So now that you are in, to hell with everyone else, right?
     
  2. OmniverseProduct

    OmniverseProduct

    Joined:
    Feb 26, 2012
    Posts:
    1,568
    That's a little inconsiderate.
     
  3. Dreamora

    Dreamora

    Joined:
    Apr 5, 2008
    Posts:
    26,601
    I agree partially on this.
    But partially I disagree because its not always a feature that it works. The US compiler itself has had quite a few bugs and still has. It took until Unity 3.4 for example to finally throw compile errors when you tried to access private variables on other scripts, an absolute basic thing one would have assumed to not even be up to discussion. And as if that weren't bad enough, this fix has also shown that even 'US evangelists' program more or less bad code which rides on the various US compiler bugs as their products simply failed to compile. This even includes Erics Vectrosity and I consider him to be one of the most knowledgable community active users Unity has and likely one of those knowing US best beside the developer himself. This shows the extend to which the lack of documentation and presence of compiler bugs impacts US existance.

    Also US has one fundamental problem which basically disallows this totally incorrect 'beginner friendly' classification to be used beyond Unity 2.0 as Unity iPhone was branched out from 2.1 originally and that is that the stuff you do here relies on features only available on desktop and webplayers (dynamic typing, some forms of the dynamic type inference and more). These will not work on mobile nor many other platforms. on those platforms you commonly will do exactly the same thing as with C#, properly casting the stuff, just that you don't know about it upfront - at times not even at compile time - and then get struck with a whole pile of compiler and runtime errors (as #pragma strict is unfavorably still optional outside the AOT platforms) and little to no documentation as US does not exist outside Unity


    And then there is the other problem which you seem to ignore and that is that US still runs on .NET and many of its user want to use .NET features as if they were really using a .NET technology. But to do so US has to learn proper .NET interaction and offer the required capability. US due to this has moved seriously towards C# (generics, delegates and a few other things) in the past 2 years, basically sacrificing its identity up to a given point as its no longer a simple 'AS - JS' alike language, its more a genetic experiment by mad scientists trying to cross ECMA with C# with WTH
    And that won't get any better once Unity upgrades to mono 2.10 with .NET4. Instead it will be even more unfavorable for US as already C# 3.5+ as present now is generally easier than US (it works correctly, has the variable datatype for rapid coding and has thousands of pages and tuts)

    And last but not least: most who consider US so much more userfriendly that C#, at least those talking about it loudly on the board, often seem to have little knowledge about what C# is, especially in the higher versions (3.5+ as supported in unity) offer like the variable datatype (by C# 4.0 then the dynamic datatype completely removing any need and use for US if you ask me), anonymous objects and functions and many more things. And did I mention LINQ - PLINQ or a proper, supported, working IDE (VS + ReSharper or at least the real monodevelop. Unity messed up their quite outdated MD version very badly and it didn't get really better since Unity 3.3) - not a pretend to be working IDE as Unitys MD + US addon.

    I agree that Unity needs a second non-coder friendly language though.
    But I totally disagree that UnityScript is or ever will be this language as its a large mess of stolen concepts, doomed by the need to offer more and more of .NET and C# alike syntax (generics, delegate and once they exist, events will likely be part of this list too) for which they will borrow most stuff from C# too and then the whole mess glued together through ECMA as core.

    What I don't get is why there are so many claiming that learning US is easy but C# is hard: Anyone who can program in US can learn C# in the same or less time - beside lazy wanna be devs who don't want to learn programming at all - because C# has thousands of tutorials and learning resources, not <= 10 as US. After all, ECMA is nothing more than a glorified successor of C-Script and shares more with C# than it offers things different from it. The only real difference is that its code is hard to read and grasp fast as they thought it would be a good idea to have the type declaration at the end of the line (especially on functions) / variable instead of it being at front where you could grasp it within < 1s


    To really offer a non-coder alternative to C# Unity either needs to seriously invest in Boo (unlikely to happen as it would have happened long ago otherwise, after all the US creator is the Boo creator and maintainer and US relies on boo too), or what I would prefer, drop it in favor of IronPython or IronRuby (fight for all eternity on which one is better if you want to ;) I would go with Python as it has more learning resources available which is the one if not the only priority 1 decision criteria for a beginner friendly alternative to C#)
     
  4. Argenex

    Argenex

    Joined:
    Jan 7, 2011
    Posts:
    34
    I just wanted to add my voice to being against this. I am literally days away from releasing a project that is over a year in the making and for me to have to recode everything in another scripting language would effectivly be like stabbing my eyes out.

    The arguments about what runs better where... I have run tests and truth be told the results were so insignificant switching from JS didn't matter.

    I am sorry but I feel this whole thread is a bit elitest and less about the already awesomeness of Unity which is its diversity.

    Thanks.
     
  5. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    Agreed it's entirely elitist. And pointless. A lot of programmers including good ones in this thread, haven't got a CLUE how the beginner still thinks. I do though, and js offers a significantly lower barrier to entry. It is actually easy to trial and error experiment in js but not so in c# - take classes for example? js generates the class for you and keeps it invisible, while in c# this needs defining.

    What if the beginner, new to game development, renames one of his c# files? oops. Not pretty. There's many little gotchas like that which experienced programmers in c# don't realise become a major problem for the beginner who should be just allowed to tinker, and to experiment at their own leisure.

    This isn't boot camp or an elitist regime; it is unity, and I believe last I heard... democratic development.
     
  6. Jessy

    Jessy

    Joined:
    Jun 7, 2007
    Posts:
    7,325
    Last edited: Apr 20, 2012
  7. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,830
    I guess this thread is very elitist. I mean, all we asked was that you read the title, possibly a couple posts and make a rationale argument.

    I'm all for pro-US people... but I don't tolerate fools kindly.

    Oh and Hippocoder... same deal. Your argument is completely invalid... not because you don't understand beginners [though lets be honest, auto-complete and decent compiler errors are a beginners wet-dream] but because you failed to read this thread where I outlined in some detail how it is perfectly possible for U3D to remove the default imports class declaration from C#. It's been done before, and is not a limitation of C#.
     
    Last edited: Apr 21, 2012
  8. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    While I agree with you, I still don't know how we can berate people for using unity js given that unity insists on supporting it.

    I have noticed the more recent docs have c# examples first now... food for thought.
     
    Last edited: Apr 21, 2012
  9. Tseng

    Tseng

    Joined:
    Nov 29, 2010
    Posts:
    1,217
    While being quite late, got to add a few things too :p


    I got to protest against this. Generic GetComponent is not that much slower than the first version you used.

    If you load the UnityEngine.dll into IL spy and look at the GetComponents(): T method, it's
    Code (csharp):
    1.  
    2. // UnityEngine.Component
    3. public T GetComponent<T>() where T : Component
    4. {
    5.     return this.GetComponent(typeof(T)) as T;
    6. }
    7.  
    Which basically does the same, so it's not that much slower (one Method Call slower) which isn't that much (as Unity calls some 10.000's of methods every second). It's somewhat of micro-optimization argument

    The transform thing can be done in one line too, and you can update all 3 axis at ones

    Code (csharp):
    1.  
    2. // You can update 3 positions with one single line ;)
    3. transform.position += new Vector3(5.0f,0,0);
    4.  
    That's actually more of a paradigm argument. In UnityScript the compiler assumes some work for you, and most developers I know consider this as a bad thing. C# is a very pragmatic language and as such, you must define everything specifically. A float is a different type than double and int.

    some other example
    Code (csharp):
    1.  
    2. // C#
    3. int number;
    4. void Start() {
    5.     number = 5 / 2.0f
    6.  
    7.    if(number > 2.4) {
    8.       // do something
    9.    }
    10. }
    11.  
    12. // JS
    13. var number : int;
    14.  
    15. function Start() {
    16.   number = 5 / 2.0f
    17.  
    18.   if(number > 2.4) {
    19.      // do something
    20.   }
    21. }
    22.  
    JS compiles, no warning and nothing. The 2.5 gets truncated w/o a warning or error.
    C# on the other side will refuse to compile the thing, since it's an obvious error. This can be a common mistake, when a user declares a member variable and his code becomes long and he type code like this somewhere (where he doesn't see the declaration).

    Unity assumes some behavior and does it. This can leads to undesired/unexpected behavior and a user may wonders why his code compiles and rubs, but he doesn't receive the results he is expecting and may spend hours or days hunting down the bug.

    For the same reason Microsoft enforced if/while/for expressions to be boolean type. Iirc in C++ something like that was possible

    Code (csharp):
    1.  
    2. while(1) {
    3. }
    4. while(pointer) {
    5. }
    6.  
    7. int condition = 1;
    8. // condition is set to 1, hence always true and you will have an endless loop
    9. while(condition = 1) {
    10.    if(/*some condition*/)
    11.       condition = 0;
    12. }
    13. // intended
    14. while(condition == 1) {
    15.    if(/*some condition*/)
    16.       condition = 0;
    17. }
    18.  
    This lead to non-bool types being allowed in expressions which sometimes caused confusion, when people for got an = sign. Both compiled to valid code, but the missing = caused a different behavior (in this case a lockup due to endless loop). That's why only why if/while/for now only accept expressions which result in a boolean.
    Code (csharp):
    1.  
    2. // doesn't work anymore in C#
    3. int number = 0;
    4. if(number = 5)
    5.  
    6. // doesn't neither, its not a bool
    7. if(number)
    8.  
    9. GameObject go = null;
    10. // doesn't work neither
    11. if(go)
    12.  
    13. // but this does work
    14. if(number ==5)
    15. if(number != 0)
    16. if(go!=null)
    17.  
    It's basically enforcing developers (especially beginners) to clearly declare their expressions which avoids errors. It's a design question and one about paradigm, as it can catch up mistakes at compile time.


    Indirectly it does have an impact, like it or not. Due to US (and probably Boo, dunno) limitations, the whole UnityAPI had to be done in a way, which complies US/Boo capabilities, instead of fully utilize what C# has to offer.

    For example LoadLevelAsync/LoadLevelAdditiveAsync where API got sacrifised in favor of Language compatibility.

    In C# world you would subscribe to an event, something like
    Code (csharp):
    1.  
    2.     LoadLevel ll = new LoadLevel("MyNewLevel");
    3.     ll.IsAdditive = true; // or ad an overload to LoadLevel and instantiate it with LoadLevel("MyNewLevel, true);
    4.     ll.Progress += delegate(string name, float progress) {
    5.         Debug.Log(string.Format("Loading '{0}'... {1:P} completed. ",name, progress));
    6.     }
    7.     ll.Complete += delegate(string name) {
    8.         Debug.Log("Level loaded and ready");
    9.     }
    10.     ll.BeginAsync();
    11.     //ll.Load() // do synchron call
    12.  
    You got a clean API, you can configure your level loading object and fire it when you are ready. Instead, the API had to be sacrificed, because US doesn't support events. Same goes for GUI, there is no way to configure the UI ONCE and then register events etc. and only cal "Draw" methods in the OnGUI call but you have to render it several times a frame.

    Some other thing is SendMessage/BroadcastMessage methods. There is no need for such Methods in a well designed C# project. But in UnityScript there is no easy way (other than creating component array and loop through then and call each of its members or working with MulticastDelegate class) to do it in US, so they made this "shortcut".

    While I'm sure beginners appreciate the easinesses of using it, it really mess up the overall API


    I don't see this as an issue. Unity isn't actually a tool for people with no programming knowledge at all. People should already have some kind of programming experience before (even if it was "just" ActionScript3) and not start learning programming at the moment they decided to make a game.

    Though C# gives you the power to make your classes not derive form any other, while in Unity3D everything is automatically derived from MonoBehaviour. This has is advantages and disadvantages and you shouldn't just count one of it.


    @Topic
    Though I really thing that the API was designed horrible with UnityScript/Boo (and bloody beginners w/o prior programming knowledge), it's somewhat to late to drop any of the languages. They should never had been in to begin with.

    But to quote a popular programming joke:
     
    Last edited: Apr 22, 2012
  10. Jessy

    Jessy

    Joined:
    Jun 7, 2007
    Posts:
    7,325
    I'm sure Eric knows that; that doesn't do what his code did. I think C# has JavaScipt beat when it comes to flexibility for constructor readability under different circumstances, though:
    Code (csharp):
    1. var color = Color.red * new Color(){r = .25F, a = .5F};
    Yes it does.
     
  11. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    Make Unity C# only, and you make Unity to a elite engine for expert programmers only, or for those who think they are. Wrong direction.

    The idea to have multiple languages in Unity was to reach a wide spread user base, as big as possible. Without the hassle to relearn a new language. The idea of providing multiple language support is to provide an entry point for everybody. Unity wants to be a engine for everybody. And it is for everybody. From beginner to expert. And across three available languages. Not just for elitists, C# nazis and wannabee experts. Unity was very successful with this strategy. And you can make the same game with all three available languages. Just grab what suits your needs best. Not somebody elses needs.

    To repeat myself, Unity promises to provide the same functionality inside Unity with all three available languages. When you really find something that you cannot do inside Unity with one of the languages, then you found a bug. Please report. Useless to say that NO such bug was ever reported. Means Unity does a very good job with their promise to provide the same functionality.


    What makes me always wonder is why this faith war is always be restarted by C# fanboys. Never heard this from a Javascript user or a Boo user. It`s always just C# users that wants to split the community into "good" C# users, and "evil" JS or BOO users. C# is no religion. There is no world domination to win. It`s just one of three available languages in Unity. When you don`t like Javascript or Boo, then don`t use it and leave it alone. And please leave the Users alone then too. That simple. But you refuse to do so. So what is it? Envy that some folks can make their game without the need to study C# for three semesters first? Bigotry? Nobody has the right to use something else than my holy C#? Must definitely be something pathologic.

    Dear C# uberfans. Please leave us others alone with your C# mission.
     
    Last edited by a moderator: Apr 22, 2012
  12. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,830
    And to good programmers.

    And to intermediate programmers.

    And to novice programmers.

    And to beginner programmers.

    Anybody that can program US can program C# - that's the whole point of this thread.


    Not only is that wrong [why don't we have C# snippets?] what we do have is a lowest common denominator system where some of the API is poorly done.

    Because there are no Boo users to speak of [sadly] and because the US users wouldn't have a leg to stand on.

    Isn't it ironic that the only people stupid enough to claim that we are splitting the community, that one side is good and another bad, that it's a religious war about world domination etc. are a minority of US users?

    One of the core arguments for this entire thread is that it would unite the community [unity anyone?] and we are happy to sit here, make rational arguments, speak of our experiences and compare code. What are you doing other than using emotional language?

    And lastly, how much C# have you used?
     
  13. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    No.

    And on top of that, the point of this thread is to kick out JS and BOO as the alternatives. To let a god called C# shine. Not to proof that everybody can program C#.

    Enough to switch back to JS. JS fits my personal needs better than C#.

    Surely not. It`s just that i as a JS user would never NEVER ever try to slavery others by putting them into chains. And that`s exactly what you are trying to do here. To put me into C# chains.

    The community is already a whole, and very united. It`s you who tries to split the community here, to dominate your fan article above everything else, including logic. And i have no doubt that you would find another fan article in case you would really succeed with your C# dictatorship. Like "Death to all Unity users that uses a mesh instead the Unity terrain" or similar nonsense. I know you folks. You cannot live without something to poke others.

    Just in case you haven`t noticed it yet, i am old enough to have my own thoughts. Old enough to decide for myself. Old enough to build my own opinion. I have no problem with what you are doing as long as you don`t damage my freedom with that. But that`s exactly what you are trying to do here, you want to damage my freedom of choice. That`s where i will resist. And that`s of course where i also get emotional.

    Do whatever you want. But please leave us others alone with that "C# is best, and nobody has to use something else" nonsense.
     
  14. Tseng

    Tseng

    Joined:
    Nov 29, 2010
    Posts:
    1,217
    Yea "of course". Why don't kick all 3 of Unity3d supported languages and replaced it with a visual language, where you use click point/click drag to do "programming" then the "poor noobs" don't even have to learn programming, just here here and there and they magically create a game?

    This is the ultimately non-programmer friendly and even 10 year olds could make games this way, not? Would this make Unity3d better and attract developers who actually finish their games? I doubt ;)

    And since I bet you haven't even read half of the thread, the summary of my opinion about this thread is expressed with this quote:
    With the mistake being UnityScript and maybe to a degree Boo (I know to less about it to say anything and how much it's limiting factor to the API itself). If you take a look at the examples above you can see how UnityScript (and probably boo) introduced horrible API behavior.

    None sane mono/.NET developer would have ever done such... weird API. It's just unprofessional, because it has to be accessible from languages which doesn't support the full power of what .NET/Mono offers.

    No they don't. The lack of an visual programming language proofs that they don't want people w/o programming experience at all. And because there was something like that, though it wasn't really successful.

    Klik Play it was "noob friendly" and even my grandma could have done a "game" with it. Though, despite it being easy that even 6 year olds could use it, it didn't became a success. Why? For the simplicity of usage, the complicity of the overall engine was sacrificed and limited it's possibilities.



    I wouldn't call UnityScript a success, as most people who begin it confuse it with JavaScript and wonder why it doesn't work. And what you really don't understand is that C# isn't that much more to learn, it's just more pragmatic. At some point you'll have to learn inheritance with UnityScript too, in C# you learn it earlier on. What people like you confuse is, that they look at "C# learning curve" and include C# + .NET library to learn with, while when you compare UnityScript you only point out the UnityScript part but ignore the .NET/Mono Framework, WHICH PEOPLE MUST LEARN TOO.

    And the .NET/MonoFramework takes about 10+ times more time to learn than C# alone
     
  15. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    This is probably the first time I'm agreeing with Tiles and I am 'a bit experienced' - I wouldn't call myself hardcore, just experienced in problem solving.

    I see a lot of passionate arguments like people are championing c# to 'make the world a better place'.

    What next, you're going to start attacking people for using blender? Think about it.

    It's not the language, it's the programmer. Quite possible to get it all horrifically wrong and write absolutely god-awful bad practise c# code.

    The difference will be the individual. Perhaps we should let them vote - with their wallets. After all, that's what Unity did.
     
    Last edited: Apr 22, 2012
  16. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,816
    Yourself, and many others.. are missing the point.

    We are not attacking the language. We are attacking Unity's implementation of it, its interoperability with other languages and how it affects the API and the development environment as a whole. If both implementations were 100% transparent to the way they have been implemented.. no problem. But they aren't.. and that is what we have a problem with.
     
  17. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    YAY ! :D

    And your solution is to DELETE the language then? Great solution. As told, when you don`t like the language, then simply don`t use it. But don`t tell me what i have to use.

    Offtopic, but KnP was a big success in its time. Its followers weren`t this successful because of many bugs and its performance. But they were more than successful too. Tools like Gamemaker are big part of the game industry. Not because somebody made professional games with it. But more than one developer has started his carrer with such non programming tools. MMF, the grandchild of KnP. is still around. And gets used to create flashgames and iOS games nowadays.

    Sure, this non programming approach was more a hobby approach for a long time. Because performance was and is a big issue for such tools. But lots of apps aren`t longer coded in the traditional way, but created with such non programming tools. Flashgames, which is a big market is more and more dominated by games made with such tools, and not longer by games that are handwritten with Actionscript.
     
    Last edited by a moderator: Apr 22, 2012
  18. Tseng

    Tseng

    Joined:
    Nov 29, 2010
    Posts:
    1,217
    Funny enough, all of your UnityScript supporters haven't addressed the API thing once and how it got crippled at certain places in order to stay compatible with UnityScript Co.

    If you skip/ignore an argument it doesn't mean it's valid.

    In the end nothing will change, they made the mistake of adding UnityScript and in the big it "backfired". It's too late to remove it. Microsoft did similar mistakes with .NET too.

    In the beginning it was supposed to be Delegates and MulticastDelegates. Though soon after the first version they realized it makes no sense, and all Delegates are Multicast Delegates now, but due to histoic reasons there are still two Classes in the Framework: Delegate and MulticastDelegate, where the later one contains all the Combine/Remove/Remove all functionality. S*** happens, but once you release something bad, you can't remove it that easily in the world of APIs.
     
  19. Jessy

    Jessy

    Joined:
    Jun 7, 2007
    Posts:
    7,325
    Again, http://content.gpwiki.org/index.php/Picking_a_Language#So_which_languages_are_good_for_learning.3F.
    I can't take you seriously on this; it's obvious you don't know enough about the languages yet. Which goes for anyone who champions UnityScript. ;-)

    How is that an argument? All 3D apps do something the other ones don't, with a different methodology. No language costs any more to use in Unity than any other. If C# were Blender, UnityScript would be Blender. With features shut off.

    As far as I know (been around since 2006), Unity never offered a release that supported more languages; it's been the three all along. So I don't think you can measure this. I would be interested to see what the language of choice/license money paid ratio is, though.
     
    Last edited: Apr 22, 2012
  20. alexzzzz

    alexzzzz

    Joined:
    Nov 20, 2010
    Posts:
    1,447
    Oh, you have convinced me. I have nothing to say against this argument.
     
  21. Demigiant

    Demigiant

    Joined:
    Jan 27, 2011
    Posts:
    3,239
    I personally come from ActionScript 3, so Unity having UnityScript was initially a bonus, and I jumped into that. But after a few weeks I realized there were too many missing features (and that UnityScript wasn't as "serious" as ActionScript 3), thus I learned C# and moved to that. The switch was quite easy and took less than a week (though I wasn't immediately an expert, obviously).

    Anyway, personal biography apart, now I love C#, but I really believe that Unity is stuck with UnityScript. Also, if someone wants to use one language or the other, and there's the possibility to do that, why not? That's cool. The real issue (which was quite evident in this thread, before getting into a war :p) is that Unity's languages don't merge well together. So, for example, creating plugins (for the Asset Store or whatever) that work with all languages prevents the creators to use a language's full potential (like C# extensions). What I'd really like is to have a better version of UnityScript (and maybe Boo, though I don't know it enough to determine it's weaknesses), which could work really well with C# scripts and viceversa.

    Also, let's not forget that the mess that is Unity with class naming (meaning there's no support for namespaces, and you have to use absurd prefixes for classes to avoid conflicts - unless you use DLLs) is due to the current version of UnityScript (which wants to imply too many things when creating a class). So again, yes to UnityScript, but make it better, damn! :p
     
    Last edited: Apr 22, 2012
  22. kablammyman

    kablammyman

    Joined:
    Nov 22, 2010
    Posts:
    507
    As i said in my earlier post, if someone doesn't want to learn C# to use unity, then maybe they shouldn't be doing the coding. However, maybe a good compromise for vets and newbs alike is to just drop US. Seeing as Boo and C# are real languages that you can use outside of unity means that there is support and resources outside of this forum. I'm not just talking about unity api, but language specific help, a non-buggy compiler, not having to inherit from monobehaviour, etc.

    C# is pretty easy to learn, but if for whatever reason its not to someone else, there's boo. Its language was made on top of .NET and is designed to be very readable...i believe it was inspired by python? (i remember learning the basics of python easily in a day for my first job out of college, so i image that boo would be the same for most people who are dedicated to game dev)

    Also, I really dont see how US is easier to learn than C# really. Whats so easy about it? It cant be the syntax...its kinda similar to C#/Java/C. Is it the fact that you can make a lot of mistakes without getting yelled at by the compiler? If that's the reason, then that is a terrible reason!! If you tried to learn a new skill, and your teacher never told you that you were doing stuff wrong, does that make him an easy teacher, or just a bad one? All that does is make you pick up bad habits. How is that good for a beginner?

    Maybe some say its beginner friendly because you SOMETIMES can get away with less typing? How is being more vague easier? Its not easier to understand for someone else to read your code, and it will be confusing to you when you come back to your code after 6 months. The less typing makes it easier to make mistakes, or do things without understanding what you are doing.

    Now, if unity was really about helping the beginner, I feel they should have used BASIC instead of US. BASIC is super easy to use! I mean, c'mon look what basic stands for (Beginner's All-purpose Symbolic Instruction Code). It also been around since what...the 60s? Lots of resources and outside help for that!

    In the end, the time and effort unity puts into US can be put in a lot more places like better programming and debugging tools, a cleaner api, and maybe even more C# functionality that's been locked away (damn i miss pointers) and this why people are saying that US is holding us ALL back as a community, it would be wise to deprecate it, and move on to help unity grow as a game dev tool.
     
  23. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    Folks, again, you are NOT the ones who has to decide what i have to use. No matter what arguments you introduce or how hard you bash here. That is alone MY decision. To tell me that i am too dumbassed to make a game when i am not willing to use C#, like told here now more than once, doesn`t help neither.

    Grow up.
     
  24. OmniverseProduct

    OmniverseProduct

    Joined:
    Feb 26, 2012
    Posts:
    1,568
    I love that picture. It acurately fits some of the people here.
     
  25. Tseng

    Tseng

    Joined:
    Nov 29, 2010
    Posts:
    1,217
    Ruby is my favorite example of why shorter code doesn't mean easier to read or maintainable code. One of Ruby's core philosophies is to have the scripts as short as possible, which imho hurts the overall maintenance and readability of it.

    For the third time in a row, you ignored to address the API issues which were a direct impact of having to support languages like UntiyScript.

    To quite myself:
    You obviously have no arguments, hence you ignore the facts and you avoid and constructive discussion and instead insists on your personal opinion, which is not objective. If you have no arguments, how about stfu?

    I ask you for a last time about your pro/con arguments about the messed up API, because they have to be compatible with some Languages like UnityScript doesn't support the proper language features to implement a proper API.

    Actually it fits some of the UnityScript users here, like Tiles himself. People like him whine around, but he's unable to bring a real constructive argument about it and ignoring the API mess-up consequently.
    People like him are the ones who want to "voice" their opinion w/o arguments, when the C# people at least (mostly) brought valid arguments, most of the UnityScript crowd didn't other than "less typing" argument, which is wrong in most cases (UnityScript with #pragma strict actually mostly has longer typing in most cases)
     
    Last edited: Apr 22, 2012
  26. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    I don`t ignore anything. I am just not longer interested to discuss with people like you. I did that one time too often. My arguments either gots ignored or abused or bashed and whatelse negative things. Everything happened but a useful discussion. Always. It makes no sense to discuss about this issue. It always ends in nothing but trouble. This discussion here already shows that again. Like your attitude here to blackmail me to a statement that you can bash afterwards. Or the attitude that you put your personal opinion above my personal opinion, stating that your personal opinion is nothing personal, but mine is. Or the statement that somebody that is not willing to use C# better gives up coding. Or ...

    A discussion is useless here. A discussion is not longer necessary anyways. I already decided to use JS. I don`t need help at this decision, nor do i need a dictator that tells me what i have to use.

    When you hate the api of JS then don`t use JS. When you see a bug at it, then report it. But don´t tell me what i have to use.
     
  27. Tseng

    Tseng

    Joined:
    Nov 29, 2010
    Posts:
    1,217
    There is no "API of JS/US". UniyScript is a language, API comes from frameworks. And the UnityAPI is same for all of the 3 languages and that's the problem.

    I've posted two examples of it on the previous page, LoadLevelAdditiveAsync and SendMessage/BroadcastMessage. That's two examples of bad API. It's the Unity API, not UnityScript. But the API was done this way, because there are no "easy" ways to handle events in UnityScript. It doesn't matter if you use Boo, C# or US you are bound (some may say doomed) to use it.

    That's the prime example of why you produce BAD API, when you have to support a product like UnityScript and keep backward compatibility.

    The current built-in GUI is also a prime example, since it's not event based and it's a real nightmare trying to make a GUI this way. when you want to change color of a Text label for example (after hitting a button) you have to mix up your "GUI logic" to gether with "GUI Drawing logic", which is an absolute no-go and will soon get a nightmare to maintain.

    Code (csharp):
    1.  
    2. // member declaration
    3. Color default = Color.white;
    4. ...
    5. void OnGUI() {
    6.    Color color = Color.white;
    7.    if(GUI.Button(new Rect(...), "Red")) {
    8.        color = Color.red;
    9.    }
    10.  
    11.    GUI.color = color;
    12.    GUI.Label(new Rect(...), "I am some text");
    13.    GUI.color = defaultColor;
    14.  
    15.    // WTF??! setting 2 variables and changing back and forth.
    16.    // When you get 50 GUI elements you will have spaghetti code
    17. }
    18.  
    In C# with objects and events you'd do something like
    Code (csharp):
    1.  
    2. // member delcaration
    3. Button changeColor = new Button(..., "Red");
    4. Label textLabel = new Label(..., "I am some text");
    5. ...
    6. void Start() {
    7.    changeColor.Click += delegate(object sender, EventArgs e) {
    8.        Button button = sender as Button;
    9.        if(button!=null) {
    10.            label.color = Color.red;
    11.        }
    12.    }
    13. }
    14.  
    15. void OnGUI() {
    16.    // this would actually be useless in an OOP/event based GUI as the engine itself should be drawing them if necessary
    17.    button.Draw();
    18.    label.Draw();
    19. }
    20.  
    The second code is easy to maintain and extend, even when the GUI gets more complex. Each GUI elements has a reference, which you can change at any point in the current cycle and it will be applied when it's drawn. But in Unity GUI you have to move this logic inside the GUI draw code and do it in a specific order, which is very very very limiting and hard to maintain.
     
  28. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    And this has exactly what to do with the question to trash JS/Boo in favour to C# ? That you get a cleaner API with just maintaining C#, even when that means to cut away half of the users? Lovely. And why does it need to be C# and not JS that is allowed to survive?

    See, that`s what i mean with a useful discussion. There is none.
     
    Last edited by a moderator: Apr 22, 2012
  29. Tseng

    Tseng

    Joined:
    Nov 29, 2010
    Posts:
    1,217
    It's not about "just maintaining" C#. If UnityScript would have the full language feature set of C# (i.e. supporting C# style event subscriptions/unsubscriptions), this wouldn't be that much of an issue, since you could use similar code in US too. But it's not the case and the APi is already pretty much f*ck up in certain areas (GUI).

    On the other side your lack of ability to reads, makes you sound like an idiot, since I already stated several times, that it's too late/impossible to remove one of the Languages at this point of time. Though, the facts still stand that the API has greatly suffered because of the backward compatibility to UnityScript and there haven't been a single argument from US users to proof me wrong.

    If this thread any point/impact, it would be the one to make UT clear that US has some flaws and that they need to add ALL OF C# LANGUAGE FEATURES INTO UNITYSCRIPT AND BOO and once they have done this, they can build up the Unity API from scratch.

    TL;DR;
    1. Add Events/delegates/linq/extension methods to UnityScript Boo
    2. Scrap the current API
    3. Make a new API which is OOP based

    = all win. Because the current course of action will be some limiting factor for advanced developers.
    There are plenty of mid-sized companies who use Unity3D, it's not just the 1-3 man indie teams, and I can tell you these companies couldn't care less if you have to cast everything in US or not and safe 2 lines in code in certain situations.

    What they care are: Clean code which is easy to extend and maintain. Part's of current Unity3D API doesn't fulfill this requirement.

    edit1
    For the sake of an example
    Code (csharp):
    1.  
    2. var button : Button = new Button(..., "Red");
    3. button += function(object sender, EventArgs e) {
    4.    button.color = Color.red;
    5. }
    6.  
    Wouldn't make UnityScript or more less readable, but it would support anonymous methods and C#-like event handling, while still maintaining the US/AS3 like syntax

    edit2:
    By bringing UnityScript and Boo close to C# in terms of language features (not about syntax), the limiting factor of the current API could be thrown away in the next major version (4.x series) for the favor of a clean and well designed API (which is currently not possible, due to the factors I said above)
     
    Last edited: Apr 22, 2012
  30. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    Thanks for providing the proof :)
     
  31. Tseng

    Tseng

    Joined:
    Nov 29, 2010
    Posts:
    1,217
    You are just proving myself, that you lack the ability to read and that I'm right. You always skip the argument, because you have no counter arguments and you are a bad loser and a fanboy. Fanboys never have arguments to proof their points
     
  32. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    Rofl :D

    You are really a poor soul. But that`s your problem :)

    I have reported you now for being rude again though. That`s enough.
     
    Last edited by a moderator: Apr 22, 2012
  33. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,816
    If you have points and a case to make for JS then do so. Then tell us why JS should be the one allowed to survive.

    As Tseng stated you post no facts or arguments in JS's favour
    (Others have made factual cases for JS in this thread, yet I still have to see you contribute to this thread by posting some of your own)

    Instead you play the man.. not the ball. Provide some useful facts and discussions to this topic or leave it alone.
     
  34. Jessy

    Jessy

    Joined:
    Jun 7, 2007
    Posts:
    7,325
    Tiles, you killed off any usefulness this thread had. I'm out of here.
     
  35. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    OK, let's not start with personal insults. (And it's rather poor form to report someone for "rudeness" while being rude yourself.) I dropped this thread a while ago after it became apparent that there was, shall we say, a certain difficulty separating opinion from fact, which is pointless arguing against. This notion that Unity has "bad design" because of Unityscript, for example, makes no logical sense at all. Unityscript is their own custom language; they can do whatever they want to it whenever they want. And they have been doing just that all along. If they thought it was important for Unity to do something in a way that depended on a language feature, they'd simply make Unityscript have that feature. Just like that. If anything, they're more limited by C#, because they have some obligation not to change it to suit their own usage (and don't pretend that C# has every possible language feature ever, because it certainly doesn't).

    No, the design was the result of the usual process: someone thought it made the most sense at the time. OnGUI, for example, was deliberately designed as immediate mode; I doubt Unityscript had anything to do with it. Some people actually like that it's immediate mode...I'm not one of them, but you should recognize that not everyone thinks the same way. I know it's frustrating when you think it's "obvious" that something should be done a certain way, but really, you have to accept that it's not obvious to everyone, and that almost all designs have both benefits and drawbacks. You can ignore the drawbacks because they aren't important to you, but that doesn't mean they aren't important to someone else.

    Which, by the way, is the reason Unity shouldn't drop everything except C#. The relatively minor confusion generated by having three languages is outweighed by accommodating more people.

    --Eric
     
  36. actuallystarky

    actuallystarky

    Joined:
    Jul 12, 2010
    Posts:
    188
    I would say the only reason that continuing with three languages accommodates more people is that there were three languages to start with. Does anyone seriously believe that tens of thousands of Unity users would have never entered game development if Unity had only supported C#? Like myself and others keep pointing out, C# actually provides a better learning environment.

    For whatever reason and surely with the very best of intentions, UT decided to create their own language and promote it as the "default" option, at least in the beginning. Now the foremost reason to keep that language is not usability, functionality, or beginner-friendliness but simply legacy. To get rid of it now would cause huge problems to a large number of people for little gain.

    And so, although I agree with the spirit of the OP's proposal and many of the points raised since, I can't see the abolition of Unityscript ever happening and think doing so would be hugely harmful to UT. So I'll just shrug and continue using the best games development environment that has ever existed while using the language of my choice.

    Happy coding everyone.
     
  37. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,830
    How about you simple say that 'your decision' is that you want to continue to use US?

    What you're doing now isn't doing yourself any favors what-so-ever.
     
  38. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,830

    I just wanted to point out that the above is a tad convoluted. I'd personally do something like:

    Code (csharp):
    1.  
    2. // member delcaration
    3. Button changeColor = new Button(..., "Red");
    4. Label textLabel = new Label(..., "I am some text");
    5. ...
    6. void Start()
    7. {
    8.    changeColor.Click += x => label.color = Color.red;
    9. }
    10.  
     
    Last edited: Apr 23, 2012
  39. rqpaine

    rqpaine

    Joined:
    Oct 6, 2011
    Posts:
    69
    well Im a C3 user. I know as3 ok. I have barely ever used Javascript. Unityscript is even weirder. I know Python ok, but Im not fond of it. I like C#.

    I dont think they should drop JS/US (heh, jesus) but I do think they should drop Boo. I have never heard of Boo and I dont think anyone uses it. Pure Python maybe, lots of apps use Python for scripting. I think C# should be the preferred language, with most tutorials, API references and examples written in it. JS/US should be kept around for beginners and really simple scripts an artist might use where C# is overkill. In many cases, simply making an object rotate or animate when a player gets close, starting or stopping a particle effect etc, is a matter of a few lines of code. In these cases, where a level designer or artist wants to add some functionality, a behavior, JS/US is plenty and having them get more versed in C# and its complexities is unneeded.

    My stance is to deprecate Boo, maintain JS/US and push C# to the forefront of development, with all further documentation geared towards it, with basic behavior examples given for US.
     
  40. Diviner

    Diviner

    Joined:
    May 8, 2010
    Posts:
    677
    ^This.
     
  41. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    Funny, i thought that i said this a thousand times now.

    What you say with this picture, Jessy, what you say. That`s why i don`t want to discuss with Tseng and folks like you anymore :)

    I haven`t killed the thread. I just provided the mirror so that you can see what you guys are doing here. This thread was never useful for anybody else but the folks who wanted to have a canvas to paint their C# god at.

    I don`t have to explain or to defeat why i use JS. It`s more than enough that i do use it and that i am a more than happy JS user to prevent it from being deleted by a handful people who thinks that their language is the only true language. You would damage me with that. You would hurt me with removing JS. That`s why i am in this discussion. To defeat my freedom. Not to swap useless and ignored arguments with the other side.

    Freedom is in the first place the freedom of the others. You want to cut this freedom. And so i resist.
     
    Last edited by a moderator: Apr 23, 2012
  42. c-Row

    c-Row

    Joined:
    Nov 10, 2009
    Posts:
    847
    So following this discussion I tried to change my current project from US to C# to see the differences myself.

    Well, on the plus side...

    • like it's been said before, autocomplete and intellisense are a great feature, though that doesn't seem to be a language specific issue since this also works with US in MonoDevelop, even if a bit shabby. I guess that extensions like Devin Reimer's iTween Parameter Code Hinting add some serious benefit, though.
    • assets like Tasharen's NGUI work out of the box without having to move parts of it to a specific folder to US can access them

    ... while on the other side...

    • some things just work in US when in C# you have to import the specific namespace first (Generic Lists or example). This can give a newbie quite a headache, especially since most examples only tell you how to use this in code, but not which namespace they need to import in the first place.
    • [Serializable] - I mean, seriously? What's the point in having to explicitely tell Unity that I want to show an object and its variables in the Inspector? I was only able to track down this issue yesterday after some extensive Google searching, thinking that my code was wrong when all I was missing was a single word nobody ever told me about. In US this just worked out of the box.
    • the "new" keyword seems pretty unnecessary for simple things like "Vector3 myPosition = new Vector3(0,0,0);" - you would think that unless you specify an already existing variable it's clear that I just want to use an on-the-fly Vector3.

    I didn't run into any other issues for now, but then again my game is in a state where I don't need advanced features like those mentioned some pages ago and US was more than capable of doing what I wanted it to. Keep in mind that this list gives my first impressions after freshly switching to C# and are pretty specific to my current game, so some of you will probably points their fingers at me and laugh about these issues, but you can't discuss my personal experience away. ;)
     
  43. Demigiant

    Demigiant

    Joined:
    Jan 27, 2011
    Posts:
    3,239
    @c-Row: as I mentioned I'm now a C# lover, but I'm pro US (though I'd really want to see it improved), so I'm writing just to share some infos that you might find useful, not to convince you to move to C# :D
    • Same as US, you don't need to write [Serializable] in C#, unless you're trying to serialize a private variable: public variables are serialized and shown in the Inspector automatically. On a side note, consider that, when something is set to serialized, it's not simply shown in the Inspector, but it's also saved. Which means that, if you want to initialize a variable with a different value, and it's already been serialized, you will have to "reset" it via the Inspector (which is sometimes a nuisance, that's why sometimes forcing variables NOT to be serialized is useful).
    • Namespaces are cool! :D Yes, Unity automatically imports the Generic List, but then, if you don't use it in your class, MonoDevelop will start firing warnings like "System.Generics is never used", which is very annoying :p
     
  44. alexzzzz

    alexzzzz

    Joined:
    Nov 20, 2010
    Posts:
    1,447
    I almost never specify namespaces manually because of two reasons:

    1) When I write a name of a class that is located in a different namespace, Visual Studio automatically offers me to add the reference to that namespace. The only thing I have to do is to accept the offer. I don't even remember what is the correct name of the namespace that contains generic collections because I've never typed it manually.

    2) I often create MonoBehaviour scripts inside Visual Studio instead of inside Unity. The default VS template for C# files already contains a bunch of the most useful namespace references. But you can edit the default Unity's C# template too if you like:

    Code (csharp):
    1. #region Usings
    2. using System;
    3. using UnityEngine;
    4. using ...
    5. ....
    6. ...
    7. ...
    8. ...
    9. ...
    10. ...
    11. #end region
    12.  
    13. public class CustomBehaviour : MonoBehaviour
    14. {
    15.  
    16. }
    It's an artificial problem that UT could eliminate very easy if they wanted to, but they prefer to spend the time on Boo instead.

    The 'new' keyword makes a distinction between an object creation and a function call. Without 'new' these actions look absolutely the same. In the case of Vector3 you don't usually care because you know that Vector3 is a class (a struct actually). But when you read someone else's code the 'new' keyword omission is a bit confusing. Most of the time when C# looks more verbose, there's a reason behind.
     
    Last edited: Apr 23, 2012
  45. Demigiant

    Demigiant

    Joined:
    Jan 27, 2011
    Posts:
    3,239
    C#/US argument apart, you can't consider Visual Studio as the tool of choice for Unity, or for choosing a language. Mainly because the Pro version costs a lot (so only pros will have it), while MonoDevelop is better than Visual Studio Express (used them all, so I know what I'm talking about :p).
     
  46. Tseng

    Tseng

    Joined:
    Nov 29, 2010
    Posts:
    1,217
    If you have no arguments to contribute, then don't post at all. You just posted walls of texts with yadda yadda yadda and not one single argument.

    How is this an argument? You got to do the same in UnityScript too.

    In unity a script like
    Code (csharp):
    1.  
    2. #pragma strict
    3. var number;
    4.  
    5. function Start () {
    6.  
    7. }
    8. [CODE]
    9. Won't expose it's public members neither, it will make the arrays assignable. You must do something like
    10.  
    11. [CODE]
    12. class Test extends System.Object {
    13.     var p = 5;
    14.     var c = Color.white;
    15. }
    16.  
    In UnityScript to expose variables in the same way you'd do with [Serialize] in C#

    Code (csharp):
    1.  
    2. using UnityEngine;
    3. using System.Collections;
    4.  
    5. [System.Serializable]
    6. public class TestObject {
    7.     public int p;
    8.     public Color c;
    9.  
    10.     void Start () {
    11.    
    12.     }
    13. }
    14.  
    Edit
    Speaking of which: UnityScript doesn't even seem to serialize/expose a [System.Serializable] object which was written in C#, which just adds more weirdeness to UnityScript and lack of Mono compatibility, which is one more thing why Unityscript needs to adapt more of C# language features and use it.
    /Edit

    One of the reasons why serialization is needed, is because it gives the compiler a Hint, to mark all public and private fields as serializable which is necessary if you want to convert a object into some other form of data (XML, JSON, save it into a binary file). As said above, C# is very pragmatic and won't do things automatically for you unless you tell it to do, which is important in order to prevent unexpected behaviour
     
    Last edited: Apr 23, 2012
  47. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    Oh, i have already written some arguments. Here, and in other threads. And it always ended with

    a) they got igored or twisted or abused, not accepted as arguments, not to be valid
    and
    b) i got slapped and got yelled to be an idiot, fanboy, bad loser, moron, whatelse nice words.

    As usual. So again, why should i bother to discuss with people like you at all then? You are not adult enough for a useful discussion.

    The title of this thread asks for removing JS and BOO from Unity to favour C#. And i am heavily against this. My argument was and is: i am a happy JS user, and i would not be happy with C#. And that`s the most valid argument that counts. The reasons lies in the differences between JS and C#. And they exist, else JS and C# would be the same language. The detail is of no real interest. Interesting is just that i am happy with JS and not so happy with C#.

    And you will ignore this argument again. As usual. And when we would go on with discussion you would start yelling again. As usual.
     
  48. c-Row

    c-Row

    Joined:
    Nov 10, 2009
    Posts:
    847
    ARGH! First reply got eaten by a hotkey...

    No worries. :D I don't think I will switch this project back to US now that most parts are C#.

    Nope - once I delete the [System.Serializable] from my class, the GenericList's contents don't show up in the Inspector anymore. Just tried it.


    Visual Studio is all fine and dandy, and I use it on a daily basis at the office, but it won't help me with Unity on my Mac. ;)

    See, now that makes sense.


    I don't know if it's an issue with switching from an array to a GenericList then, but with US they showed up in the Inspector just fine, even without the "extends System.Object" part.


    [edit] My definition of the clsItem class is nested within another class rather than its own. Could that be a probem?

    Code (csharp):
    1.  
    2. using UnityEngine;
    3. using System.Collections;
    4. using System.Collections.Generic;
    5.  
    6. public class ItemManager : MonoBehaviour {
    7.        
    8.     [System.Serializable]
    9.     public class clsItem {
    10.  
    11.         public string name;
    12.         public int weight;
    13.         public Transform prefab;
    14.         public int worth;
    15.     }
    16.    
    17.    
    18.     public List<clsItem> myItems = new List<clsItem>();
    19. ...
    20. }
    21.  
    [edit edit] Nope, doesn't seem to work if I put it in its own file, not even with [System.Serializable].
     
    Last edited: Apr 23, 2012
  49. Dreamora

    Dreamora

    Joined:
    Apr 5, 2008
    Posts:
    26,601

    Everyone programming in UnityScript can within less than a day learn the minor deltas to C# and develop in C#. Anyone claiming the opposite simply never touched C# and has a very stubborn fanboy attitude preventing himself from being 3-5 times as productive.
    Someone claiming that either:
    1. Does not program in US either but copy pastes code or hacks spaghetti trash (programming means you write code thats readable and can be maintained, spaghetti is when you hack around on your keyboard and write something that works kind of exactly right now but will never be of use again)
    2. Is just too lazy to learn anything related to programming in general unless he can not avoid it at any cost (as anyone else would at least be interested to know the other side of the fence for which professional tools exist to write code unlike US) and should potentially stick to uScript, PlayMaker, Antares Universe etc for their own good.


    I doubt everyone here wants to make C# shine, at least I want dedicated support and learning material and thats not gonna work out if 2 of 3 languages do not even comply to .NET 2.0 when we hit .NET 4.0 with Unity 4 (Mono 2.10), even less when their past track record has shown that this is not gonna change in the next years likely.

    I also want to make clear that I support this here not to push C# but to support beginners and get them a usable language with proper support, documentation and a reasonable amount of global resources and that is neither the case or Boo nor UnityScript as both have a niche to non-existance especially outside of Unity.


    Thats why at least I would favor a kick out of Boo and UnityScript (for sake of god stop calling it JS, it has nothing to do with JS at all, its C# with 4 additional features, 3 syntax differences and several hundred missing features. Not even ref and out are supported years later and thats a basic thing required to interact with many crucial .net functions!) and replace it with something thats really beginner friendly AND different from C# / C-Script. Any C-script basing language by DEFINITION is not beginner friendly.
    Since Unity 3.0 beta 6 US has lost its right of existance anyway as it simply is no longer the beginner friendly language nor even tries to be one nor even is reasonably distinct from C# anylonger as they added half arsed .NET features to please so called professional UnityScript developers (various of them are professionals but some unluckily stuborn enough to claim that a text editor like Unitron trash is more productive than MD / VS with full project wide intellisense and more for any code present not just the functions someone manually defined) and did that by doing a 1 : 0.95 clone of C# (<T> vs .<T>).
    I still get a good laugh each time I can tell a US programmer that he can not bind to public event SomeDelegate OnForgetThisIfYouAreAUnityScriptUser; and hence has to use totally ugly and slow SendMessage observer pattern implementations ... Thanks god for them Blurst shared their system years ago already and some younger users released much worse and slower system for $$$ on the asset store too.

    Hence my drive to take part in this discussion and my support toward IronPython (yes we have boo but boo is weak, incomplete and an inhouse breed too with no real world existance just like UnityScript) or IronRuby, at worst one of the .NET Luas (but then we are not much further than we are with US and Boo as Lua resources are rather scarse and the .net related ones even more so), just something that was really invented for non programmers.
     
    Last edited: Apr 23, 2012
  50. alexzzzz

    alexzzzz

    Joined:
    Nov 20, 2010
    Posts:
    1,447
    I tried MonoDevelop and consider it a BDSM tool, not an IDE. The lack of proper error highlighting and crappy auto-completion is enough. This is my personal subjective opinion. Visual Studio Express in comparison with Pro has its flaws, but not so fatal. I still use MonoDevelop from time to time for real-time debugging - it's the only reason I keep it installed.

    I would place a sad smile here. I've seen Mac users on this forum that run Visual Studio on virtual machines, just not to deal with MonoDevelop.