Ladna
Junior Member
Posts: 233
Registered: 04-10 |
It's not that JS doesn't have integers. It's that the runtime represents "integers" as doubles internally. In a scripting context this is typically not a big deal; you won't be managing a screen buffer (1920x1200 is 2,300,400 pixels) or you won't be adding something 10,000,000 times. I just use it as an indicator of how sloppy JS really is; any serious language needs "real" integers, not integers that are "mostly integers" until you do something special with them.
There's a big gap between FraggleScript (inherently insecure, prone to bugs & crashes) and JS. For all of JS's irritations, as Quasar points out it's extremely well-tested and really quite fast - and getting faster. I'm sure that whichever direction Quasar goes Aeon will be awesome, I'm just arguing for my side that's all :) .
Quas:
Haha I guess I sound a little heated. I'm not though honest! I just love to argue and talk about programming... which you will see shortly :) .
I think that as far as using an API goes, it's hard to find a language that isn't "suitable". I guess in that context the key factor is ease of embedding, "mainstream-ness" and memory management, with some smaller considerations like functions and datatypes. So really, we're really talking about any given scripting language that isn't PHP (too specialized), but it probably boils down to Perl, Python, JavaScript, Ruby, Lua, Tcl and Squirrel. Tcl & Squirrel are probably too obscure, everyone hates Perl, and you say Lua's C/C++ interface is awful, so we're down to Python, JavaScript & Ruby.
In the context of Python vs. JS vs. Ruby, I think arguments like, "looping through arrays is clumsy", "__init__" is ugly, and "really when you call a function, () around the arguments shouldn't be optional" are valid. But like you point out, a lot of the argument really is subjective. I personally prefer Python because I prefer explicitness, so when I want to define an object:
code:
class ThisIsAnObject(object):
def __init__(self, arg1, arg2):
self.arg1 = arg1
self.arg2 = arg2
my_object = ThisIsAnObject()
Compared to how you would do this in java script:
code:
function ThisIsAnObject(arg1, arg2) {
this.arg1 = arg1;
this.arg2 = arg2;
}
my_object = new ThisIsAnObject();
In another life I was an English major, so this semantic dissonance (is a "function" a "class"... what?) irks me. Pragmatically it's not a big deal, but it irks me nonetheless.
I prefer Python's inheritance, because JavaScript has no concept of "inheritance". Rather you have to hack it on yourself. Plus, you're not creating a "type", it's just another Object with some members and methods.
I prefer Python's iteration:
code:
this_is_an_array = ['apple', 'banana', 'cherry']
for fruit in this_is_an_array:
print fruit
compared to JS:
code:
this_is_an_array = ['apple', 'banana', 'cherry'];
for (var i = 0; i < this_is_an_array.length; i++) {
print(this_is_an_array[i]); // [CG] Whatever 'print()' is in JS
}
And you can explicitly create iterable classes in Python, without having to rely on "everything is really just an 'object' so just use for in/for each and hope for the best" by implementing the __iter__ method in your class (yes ugly, but still).
I believe that Python's syntax for "private" members is superior over various hacks used to make members private in JS, even though it's ugly as shit (self.__this_is_a_private_variable = 'seeeecrets'). Furthermore, Python's "property" concept is really strong. This is a contrived example but:
code:
class Rectangle(object):
def __init__(self, width=1, height=1):
self.__width = 1
self.__height = 1
self.width = width
self.height = height
def _get_width(self):
return self.__width
def _set_width(self, new_width):
if new_width <= 0:
raise ValueError('Width must be > 0')
self.__width = new_width
def _get_height(self):
return self.__height
def _set_height(self, new_height):
if new_height <= 0:
raise ValueError('Height must be > 0')
self.__height = new_height
width = property(_get_width, _set_width)
height = property(_get_height, _set_height)
@property
def area(self):
return self.width * self.height
@property
def perimeter(self):
return (self.width * 2) + (self.height * 2)
Creating even this extraordinarily simple class in JavaScript is a horrible pain in the ass. Read-only members: hack. Bounds checking on assignment: hack. Private member variables: hack. And when you're done in JS, you don't have a Rectangle. You have an Object with a few big hacks inside.
And again, I think the "you probably shouldn't be writing a big program using Aeon" holds some weight. Like you said, if it's really only there as an interface to EE's Aeon API then everything else is kind of tertiary. But why accept limitations for no reason? Were EE to grow C/S multiplayer functionality, I think it would be really cool to implement game modes using Aeon. It certainly beats extending the engine in C++. And indeed, many game engines work this way, Civ IV for example is basically a core engine and a ton of Python scripts and XML. I mean, I don't want to go the XML route, but I think it's a compelling architecture, and certainly more accessible to Doom's large community of mappers and modders.
It's maybe also worth arguing that there's no such thing as a small, lightweight JS engine. The *Monkey engines are terrifyingly enormous, and V8 is tens of thousands of lines of code... which honestly isn't that much but it's still more than you'd expect for an "embedded scripting language". Of course, JS is more than that, but a lot of people think that JS is so simple that its implementation is straightforward and small - it isn't. I'm not saying Python isn't huge - it is, but just that JS is far from popping a 128K DLL in the EE distribution.
===
CSG: Admiral Hopper was a scholar, a sailor, a scientist and a Class A lady, and she'd probably wash yr dirty mouth out with soap for using such foul language. And you would deserve it.
|
04-06-11 02:07 
