C# is a lot more like Java than Javascript is, though…should have gone with C# to begin with. 
–Eric
I don’t see how being forced to write more stuff results in better design.
In C# it takes more typing to declare stuff and more reading to see how stuff has been declared … the stuff isn’t more thoroughly declared, just more verbosely declared. It’s like arguing that “this_is_a_public_method” is somehow more informative than “public”. (OK, it probably is. Once.)
There’s absolutely nothing preventing you from writing code that’s EXACTLY the same in terms of disorganization or whatever in C# as in JavaScript.
I will agree with one thing – Mono is more of a pain to use from JavaScript than C#. This isn’t a problem with JavaScript, but it is a problem with USING JavaScript.
(A lot of prejudice against JavaScript should actually be directed at web browsers and Internet Explorer in particular, specifically inconsistent implementations of the DOM. JavaScript is of itself a very elegant language design. I speak here as a long-time JavaScript hater. It’s much like hating Java because of the AWT.)
Haha - I like those discussions. It’s fun, isn’t it?
In the end, it’s really just a matter of personal preference. Just like some people think, opening braces need to be at the end of the line and think this is much more readable, and others think that opening braces MUST be at the start of the next line, and will tell you that this is much easier to read.
Hm?
Very simply because the compiler can tell you “you know what, bro, turning this object of type UltraCoolHyperObject into a float may seem cool to you, but it might simply not be the greatest idea to do that. If you are really sure you totally have to do that, maybe at least do me the favor of offering me a proper typecast, ok?”
And, when then, some day later, you or somebody else is reading that code, you’ll immediately see the conversion:
float myNumber = (float) objOfUltraCoolHyperType;
In JS, as most people would use it, this will be:
var myNumber = objOfUltra...;
The compiler will most likely not care, but you might have a serious issue during runtime (and runtime-errors are always much harder to fix than compilation errors).
And: Wow, of what type was objOfUltra… now again? Hm… don’t remember… but since the compiler doesn’t care, why should I?
In the end, being a fan of C# (and other primarily strongly typed languages), I’d say those languages are for people who want to avoid keeping too much stuff in their minds and instead have it all “on paper”. This leaves room in my mind for other stuff I consider more important
The problem I mainly see with JavaScript is that quite frequently, you think you understand the code - but in reality, you simply don’t (talking about myself here, of course ). And the worst part about this: Once this happens (and you realize it), there’s no one there to help you…
That was my very first experience with programming in Unity (JavaScript, because most examples are JavaScript): I read the examples, and thought “ha, cool, easy”. Then I changed something, and it was broken beyond repair. There’s so much stuff implicit in the code that if you don’t really know the engine and the API by heart, I don’t think you can claim you really understand that stuff.
I started being able to do stuff “on my own” once I had everything converted to C# - because then, I didn’t have to know, I could simply read instead.
Of course, there’s some rather advanced things for which dynamic typing is really useful (which is why it was introduced for C# 3.0), but I think those are somewhat rare cases - and personally, I avoid those because it consumes more of my brain-capacity understanding those hyper-advanced concepts than simply typing out something real quick that does the same and that I’ll still understand two years from now
Sunny regards,
Jashan
PS: It would be interesting to compare the length of postings of people who prefer C# to the length of postings of people who prefer JavaScript. Some like it verbose, others don’t …
1 Like
It will care in both JavaScript and C#. You’re comparing C# to non-compiled web JavaScript. This is a “Straw Man” argument – C# is better than something that doesn’t exist.
If JavaScript in Unity were “real” web JavaScript your complaints would be valid (although not necessarily compelling – real JavaScript has many virtues as a result of being highly dynamic … but it’s a different productivity / performance tradeoff than Unity JavaScript).
Final Clarification:
In Unity JavaScript:
var foo = SomethingExoticallyTyped; // foo is now a TYPED variable of type SomethingExoticallyTyped; foo = 17; will now generate a compile-time error.
I would tend to write:
var foo : SomeExoticType = SomethingExoticallyTyped // if the type of the RHS is not clear, but it’s OPTIONAL.
Just chiming in here not having followed this (old) and seemingly never ending topic…
The short is (and has been repeated before); do what feels best to you.
As for “either or” discussion, well some of us have taken to using “typed Javascript” as a convenient (though obviously JS biased) middle ground.
Makes for very readable code with less hoop jumping, if you’re adverse to that (at the cost of some language features).
“Most of the flavour with half the fat?” 
Hey, I just want to add my saddening that Boo hasn’t been mentioned mutch in this thread. 
For me, it combines some advanced features that C# offers with a simpler and less verbose syntax. And hey, if I already sincerely indent why shouldn’t that at least benefit the compiler? 
Unity’s languages are very similar and if you don’t use some advanced OOP (e.g. shadowing) then you can pretty much interchange them and I mentally do that often with relative ease.
Curious… do you use MonoDevelop with the Boo addin?
Are you sure you knew what I was talking about? Have a look at this JavaScript file. It’s a valid “Unity JavaScript” file that compiles without a problem. But try executing it inside of Unity and you’ll see what ugly runtime errors are (simply attach it to some random game object):
var someConditional = true;
var whateverType;
iLikeTypos = 5;
iLikeTipos = 6;
whateverType = gameObject;
if (someConditional iLikeTypos == 5) {
whateverType = 5;
}
whateverType.transform.position.y = 3;
Now try to create the same nonsense in C#
Obviously, one can write it in JavaScript in other ways that are more safe (as your example indicates) - but then it’s also more verbose… I do enjoy freedom of expression, but you’d have to give me an example of what the freedom I had just used to create this nonsense script is useful for. Possibilities that have no use just create clutter and confusion
1 Like
Seems that everyone here as good points; but i think that there are different way to see the problem, since the experience of any of us is different
you know java or javascript? stick with java!
you know C++? go for C# (i love to type more because i know what i am doing, and the security to give a void to a function, compared to returning a value is sometimes very useful when you ahve thousands of lines of code…this works for me in C++ but i never tried C#, so i assume that is the same)
if you know python go for boo
if you do not know anything; learn the basics of OOP and go for JS, since is easier to learn for who is new to programming (this doesn’t mean less powerful, since AFAIK all the scripted languages are at the same speed level in Unity…please correct me if i am wrong)
I would not imagine someone starting from 0 and learning C# for Unity scripting, unless he want to use something useful and pursue a career as programmer in C# or C++ development
The other 2 scripting language are useless if you don’t work with Unity; since JS is not real Js and boo is a dialect of python.
just my 2 cents
If you know Java, you should use C#. Javascript (both real Javascript and Unityscript) is not much like Java. C# is like Java though.
–Eric
I believe C# is more powerfull soley for the fact that you can make use Object Oriented Programming. Inherting from base classes, overwriting methods and implementing Interfaces can make your life so much easier.
This is not performance-wise but design-wise.
OOP > all!
You can use interfaces and inheritance with Unity’s JavaScript. Unfortunately, method overriding doesn’t work with ad-hoc polymorphism, which defeats much of the point…
For the record, we use JavaScript and #pragma strict at Flashbang. Whichever works best for you is the right answer in any language debate, of course; the advice in this thread is solid.
Very true.
Also the ability to have propper Collections and such is a big plus, together with the more powerful features of a language like Java/C# (OOP wise)
Your example is not very fair. JS tries to infer the type of variable and then statically types it. Only if you don’t give any hint what type a variable should be it switches to dynamic typing.
I.e. if you do:
var whateverType = gameObject;
the compiler infers the type and that line is identical to:
var whateverType :GameObject = gameObject;
Changing your example like above will then throw a compile error that int cannot be converted to GameObject.
So in JS and Boo, if it’s obvious what type a variable is at the time of it’s creation (either by assigning it a value or by declaring the type), then it’s statically typed just as in C#. This is also true for method return types and even works for arrays:
// This is inferred as String[]
var myStringArray = ["one","two","three"];
Currently I’m using Komodo Edit and the Python syntax highlighting for Boo. Highlighting works well but autocompletion does not.
Agree with you Eric; the statement would be “if you know javascript stick with JS in Unity” .
Der dude: the 3 script languages are compiled by the engine, that’s why no matter what you use, it will work in the same way.
Design-wise, you would not use Unity but pure C++, or C# with XNA I am for the well written and organized code, but in this case you are working on a framework that does a lot for you, so the design part is only related to implement your features and try to not write no-sense code that simply burn cycles.
I agree that anyone can choose his language, but giving multiple choice would mean to support 3 different categories of users, and seems that this does not happen, so if you learn JS you will have a lot of material to work on, compared to Boo and C#
I can only speak about C#, and there it’s not a big issue. You have to add the stuff that’s missing in JS, twist a little bit with the syntax, and there you go. So I don’t mind that the examples and so on are mostly in JS because by converting them to C#, I can assure I understand what they do (which is better than just reading).
It’s a bit difficult as a beginner, as you then usually don’t know what the relevant classes are (because as a Unity beginner, you naturally don’t know the Unity API very well ) - but on the other hand, once you’ve been through that, you should have at least a good basic understanding…
Sunny regards,
Jashan
Then just out of curiosity I would like to know, how I can create my own abstract type with overrideable methods and implement a self-made interface using UnityScript.
I guess it depends on the complexity of your game logic. If you do the bread and butter kind of things, then surely there is no need for the higher OOP stuff.
I just want to give an example where inheritance and the features that come with it, make your life easier.
We have one script in our shooter that handles the calculation and hit detection of the shots being fired in the scene. In our game, there are different kinds of shots. Ballistic-, Pulse- and Ray- Shots are just a few of them.
Now because they all inherit from the base class Shot which declares an abstract method DoCalcStep() (which they of course override), we do not have to keep seperate lists for all of the different types of shots.
Additionally, functionality they all share (e.g. handling of a hit) is only written once and there is only one place to debug.
Der Dude:
I am sure that anyone can reply to this question better than me; I started to use the engine not too long ago, and the only noticeable difference that i have seen (from tiutorials and examples) is the way to do the things in the 3 srcripting language.
Well, your concept come from OOP programming, nothing new…do one object and create other objects that inherit the parent class methods, and add what you need (or override at will); and you can do the same thing in Unity with any script; the only difference is the way that you do things.
I am having not too many problems with C#, but i realized that multiple inheritance is not supported in JS (correct me if i am wrong); but there is no need to do MI unless you wanna program like a book all the things learned at the college are basically useless at work place; if i would have read the book at home would be the same thing, since at work we do so many dirty things while coding that is hard to follow any kind of common rule (except code formatting); and even if is bad, sadly that is the difference between when you develop with your friend (or a small team) and when you work in a corporate
OOP is a concept, is not tied to a language, and even Visual Basic 6 can use OOP concepts even if is not a OOP language (by definition); so the choice is up to you…i choose C# and JS as alternative
I never claimed that it was. Seeing as most (?) people in this forum learned coding through Unity, I thought an example would make my point clearer than talking in abstract terms.
Agreed.
Since I don’t know how to do basic OOP stuff with UnityScript, I’ll do my textbook-code in C# for the time being
In the true sense of the word multiple inheritance it is not supported in C# either, there are workarounds for it though, but the approach in C#, or philosophy if you will is more like Java, that a single rooted inheritance hierachy is the best way to do things and if you want to do something like multiple inheritance you should do interfaces instead.
Edit: Heh its even in MSDN faq: C# Frequently Asked Questions | Microsoft Learn
Regards,
Marc