Coding android games in javascript?

[HammerFist132]

I mean in unity? Can it be done, I guess it can, but in most unity 4 threads they talk about coding android games in c#, does javascript misses something that c# has? So what is better specialy for android, I learned js, and learning c# right now would be losing time.

 

[Crazed_seal2]

Probably nothing except for the "style" of the code.

I think it's either all parsed by Unity either way, so i Dont think it makes a large difference.

 

[HammerFist132]

Key thx.

 

[Adiktuz]

maybe more people do it in C# right now, so it becomes more desirable to do it using that one since you'll probably have more support if you have questions

 

[Waffle]

a) all main-stream programming languages are Turing complete -> functionally equivalent.
b) js and C# have radically different style. C# is staticalyl typed, and takes from C and java. Javascript is like the child of scheme and java and self. it is incredibly dynamic and most profficcient programmers have a tendency to levrage that at times.

of notable differences js and C# have a completely different approach to OOP. C# uses classes and instances, js is only objects and if you want a "class" then u basically say all these objects are like that other one.

 

[GhostWolf]

of notable differences js and C# have a completely different approach to OOP. C# uses classes and instances, js is only objects and if you want a "class" then u basically say all these objects are like that other one.

There is no OOP in JS, however there is prototyping. Not quite the same thing, and in fact, very unclean if you want real OOP (as in, inheritance).

However, since the main usage of OOP is in fact to hold collections of different types together (because in all honesty, inheritance is usually not the answer to any of the supposed benefits Java programmers would love to advocate to you until you die), you don't quite need it in dynamically typed languages.

Note: OOP is not objects with methods, those existed way before the object oriented hype.

All language preferences aside, using UnityScript (this is the actual term, because what Unity has isn't exactly the same as JavaScript) doesn't allow Unity to make some of the type-based optimizations. If this matters to you is a whole other question.

 

[Waffle]

@Ghost.. you don't know what "OOP" means..

Refresher.. it stands for Object Oriented Programming.
(nothing in the definition even remotely mentions a "class" or "struct" )

you want a class? Here, take this..

// class MyClass
// constructor or __init__ depending where u come from..
function MyClass(a,b,c){
this.a=a;
this.b=b;
this.c=c;
// public Number sum()
this.sum= function(){
return a+b+c;
}
}
var instance=new MyClass(1,2,3);
var sum= instance.sum();
var b= new MyClass(1,2,3).b;

does this not look familiar to you? I write this code just like i would java or c# the only difference is some small tweaks to the syntax (namely that i stuffed the entire class definition in to the constructor for brevity).

If you say "js is not OOP" I'm sorry.. but i can only conclude you are a very ignorant person.

(ok.. now that i calmed down the JS fan inside me...)

 

[Cokemonkey11]

@Ghost.. you don't know what "OOP" means..

JS in Unity isn't ECMA script but a unique derivative.

Coding for android games in unity is usually discussed in C# because the C# unity dialect offers a (little) bit more functionality than the ECMA counterpart.

As waffle has said, the two are similar because unity parses them both without a difference in performance. Unlike what waffle said, the primary difference isn't that "C# is inherently different due to things like static typing"

The two are different because unity offers a little more functionality in their C# dialect.

(end of thread)

 

[GhostWolf]

Thank you for the name calling, it will surely make the quality of your post go up to the sky.

I am not sure why you refereed to "class" and "struct" seeing how I didn't write those words anywhere.

Yes, you made an object with a few properties. No, that isn't OOP. The real idea behind OOP is inheritance, that's the whole point of OOP - describing hierarchical trees of object types, not having a structure that holds a few data/function members.
The idea of encapsulating multiple members under one name existed long before OOP.
ECMAScript is not an hierarchical language, but rather a prototype-based language. For simple cases this might seem the same thing, but for any sort of real-world code it will usually mean designing your code in different ways.

As a side note, again about your code example, that isn't even comparable to a "class" or "struct", since those would share the function.
For a comparable example, use the object's prototype.

On topic - as Cokemonkey11 wrote, UnityScript isn't at all the same as JavaScript (the web ECMAScript implementation), you can see here some of the differences.
In my opinion, go with C#. UnityScript looks like a mess of trying to write C# with ECMAScript syntax...except those languages are simply not compatible by design.

 

[Cokemonkey11]

The real idea behind OOP is inheritance, that's the whole point of OOP - describing hierarchical trees of object types, not having a structure that holds a few data/function members.

You have a good point, but you're not correct. From wikipedia:

Object-oriented programming (OOP) is a programming paradigm that represents concepts as "objects" that have data fields (attributes that describe the object) and associated procedures known as methods. Objects, which are usually instances of classes, are used to interact with one another to design applications and computer programs.

Javascript is indeed an object-oriented programming language.

Additionally, inheritance is just a design concept often found in OO languages, but not a defining factor.

The idea of encapsulating multiple members under one name existed long before OOP.

Object Oriented programming design existed long before UML, inheritance, and object instantiation (LISP, 1960s)

ECMAScript is not an hierarchical language, but rather a prototype-based language. For simple cases this might seem the same thing, but for any sort of real-world code it will usually mean designing your code in different ways.

Yes, but it doesn't mean prototype based languages can't be object oriented.

It seems to me that you're mixing up some well-defined software design concepts like inheritance with defining characteristics of OO programming.

 

[GhostWolf]

I wouldn't exactly cite Wikipedia, but just for the sake of response:

An object is an abstract data type with the addition of polymorphism and inheritance.

Saying that a dog can walk isn't strictly OOP, but saying that an animal can walk, and that a dog is a kind of animal and therefore can walk, that's the real meat of OOP. Otherwise, like I previously mentioned, we are really only talking about adding the ability to hold a collection of different types.

And just to be an ass, JavaScript has no members or methods, just hash map fields.

 

[Cokemonkey11]

Saying that a dog can walk isn't strictly OOP, but saying that an animal can walk, and that a dog is a kind of animal and therefore can walk, that's the real meat of OOP. Otherwise, like I previously mentioned, we are really only talking about adding the ability to hold a collection of different types.

The concept of "types" being "different" is precisely where object-oriented design came from (see: atoms, CLOS)

Also, the section you're quoting is marked with "The neutrality of this section is disputed." and the sentence you're referring to is not cited, much like the section further down: http://en.wikipedia.org/wiki/Object-oriented_programming#OOP_in_dynamic_languages

As you can imagine, the subject has a lot of gray area and very few strict, definitive sources.

See also http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Types_of_inheritance where I quote:

Differential inheritance is used in prototype-based programming, where objects inherit directly from other objects.

And just to be an ass, JavaScript has no members or methods, just hash map fields.

hash map fields are just implementation details - it's not for you to decide what constitutes objects or not. See: vJass (it has no members or methods, just variables and functions).

If I were to just be an ass, I could break down every component of every language (C has no integer, only series of bits) but that wouldn't make my statements a sound argument about software design

 

[GhostWolf]

You can mimic inheritance in prototype-based languages, but it becomes ugly fast. Then again, inheritance becomes ugly fast in any way it is used (as you might have guessed, I am against inheritance based trees).

Hash map fields are an implementation detail, but I really meant everything is composed of table fields in a generic object, that's not an implementation detail but the language design. This changes the way you design code in JS/Lua quite a lot.

In any case, I am both losing this "argument", and it is completely off topic, so I'll stop.

 

[Waffle]

You can mimic inheritance in prototype-based languages, but it becomes ugly fast.

Something tells me you just have little experience with prototype based inheritance.

That you have little experience with it or you have issues doing it elegantly can only describe your level of skill with the concept .. not the concept of prototypal inheritence itself.

If you try to emulate class based inheritance on top of prototype based inheritance then it is only natural that you code will be more ..convoluted...

Yet that does not mean inheritance is difficult, only that your approach differs from what the language design was geared towards.

(related note.. I'm sorry i got upset.. i should have omitted a few lines last reply..)

(and a shoot-myself-in-the-foot-note: once upon a time when JS was still a wee lil baby it had no arrays.. and then people would emulate arrays by just poking int named properties on objects..
worked surprisingly well.. except when you had a hash collision (those were rare ofc))