Re: [boost] py_cpp and ILU?

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-10-11 18:42:19

----- Original Message -----
From: "Joe Mariadassou" JMariadassou_at_[hidden]

> With so many scripting languages avialable with source (Eg. Javascript,
> Perl, Python, TCL) I wonder if there are some articles  that helps me
decide
> which one I should use. Given that Javascript is the only standard
language
> accepted by both browsers, I would have thought that more people would be
> gravitating towards Javascript. I do a little bit of Perl too. However it
> appears that there is a lot of interest in Python.  I am just interested
to
> know what Python buys me.
> joe

Guido Van Rossum, Python's author and Benevolent Dictator For Life writes
(at
http://www.pythonlabs.com/pub/www.python.org/doc/essays/comparisons.html):

Python's "object-based" subset is roughly equivalent to JavaScript. Like
JavaScript (and unlike Java), Python supports a programming style that uses
simple functions and variables without engaging in class definitions.
However, for JavaScript, that's all there is. Python, on the other hand,
supports writing much larger programs and better code reuse through a true
object-oriented programming style, where classes and inheritance play an
important role.

A colleague at work recently asked me to consider JavaScript instead of
Python for a project I did at work, so I did some investigation. Here's what
I came up with:

I just had a look through the JavaScript Guide at
http://developer.netscape.com/docs/manuals/communicator/jsguide4/index.htm.
Impressions:
1. Is this a Netscape proprietary thing? It seems like JavaScript... Okay, I
found the answers to that question at
http://idm.internet.com/faqs/jsfaq/gen1.html. All the documentation refers
to
what is supported in various versions of Netscape. Maybe I should be looking
at the international standards document instead (ECMA-262).

2. There are some odd special cases, e.g. ``Invoking a constructor without
using
new has consequences that depend on the constructor. For example, String("A
String") produces a primitive string, not an object.'' (from the ECMA-262).

3. Pg. 3 of ECMA-262 (pg. 15 of the .pdf) contains a very confusing
description
of JavaScript's prototype-based inheritance. I think it's actually simpler
than they're making it out to be. It's not clear why they describe a
constructor as having properties distinct from the constructor's
prototype. Is that just so they can get all values to be properties, even
what we would think of as local variables? Aside from that, the arrangement
looks very Pythonesque.

4. Any interesting behaviors of the JavaScript object model can easily be
reproduced in Python, I think. One could use metaclasses if neccessary, but
I
don't think you'd really need anything that mind-bendingly powerful.

5. Automatic semicolon insertion worries me. This strikes me as just the
kind of
loosey-goosey language feature that makes it hard to know what a program
means.

6. I notice that the "internal properties" of an object are inaccessible and
not
overridable as they are in Python. That's a great feature which I wouldn't
want to live without. For example, in Python, if I have a function which
expects another function as a parameter, I can substitute an instance of a
class which has a __call__() function. It's generic programming to the max.

7. I notice lots of emphasis on web page-oriented things. There are built-in
objects for dealing with web page elements. I'm not sure that is really
appropriate for an NL system's backend, but I guess it doesn't hurt to have
it there.

8. The JavaScript Guide says:
You can refer to an array's elements by using the element's value or
ordinal number. For example, suppose you define the following array:
myArray = new Array("Wind","Rain","Fire")
You can then refer to the first element of the array as myArray[0] or
myArray["Wind"].
That's really odd. What is the value of myArray["Wind"]? Can arrays be used
as general-purpose associative containers? If so, how do you determine which
is the key and which is the value?

9. I don't see any support for modules or packages. I think this could make
JavaScript unsuitable for building reusable language-independent semantic
components. It looks like JavaScript is really just supposed to live inside
a
web page, and nowhere else.

10. I don't see a JavaScript native API anywhere. One real advantage of
Python is
ease of interfacing with C/C++. Not having a C/C++ native API could
certainly
make it hard for me to integrate a semantic evaluator with a native parser.

Summary: the core JavaScript language constructs are certainly powerful
enough
for our uses, but unless I'm missing
something important it was never intended for jobs like this. The omission
of a
native interface and packages in particular seem designed to keep JavaScript
within the very specific, limited domain of web-page-oriented
scripting. Finally, it is worth considering the cost of translating between
languages. Every time you move code from one language to another you pay a
price in development time. Even if the other problems were solved, would
there
be any advantage in moving from Python to JavaScript?
-Dave