[IAEP] Which Language?

Jim Simmons nicestep at gmail.com
Mon Sep 28 10:51:09 EDT 2009


The original question was about developing Activities for a classroom
assignment, with the idea that these Activities could be widely
distributed.  With these two constraints Python is the winner by
default.  If you need to write Activities for school you need good
documentation on how to use the API's, etc.  We have that for Python,
the rest not so much.  Also, they want to put their Activities on ASLO
and make them useable by as many people as possible.  Python makes
that possible, other options not so much.

I don't agree with your performance comparison of Java and Python.  If
I wrote Read Etexts in both languages my guess is that the Python
version would perform better and use less memory than the Java/Swing
version.  That's because in the Python version Python is just used as
a glue language and the heavy lifting is done in GTK.  In Java/Swing
ALL the work would be done in Java.

I have my own gripes about Python but since my own requirements are
similar to those Caryl was asking for Python is what I use.

James Simmons

> Date: Mon, 28 Sep 2009 00:43:26 -0400
> From: Albert Cahalan <acahalan at gmail.com>
> Subject: Re: [IAEP] Which Language?
> To: cbigenho at hotmail.com, "Benjamin M. Schwartz"
>        <bmschwar at fas.harvard.edu>,     iaep <iaep at lists.sugarlabs.org>
> Message-ID:
>        <787b0d920909272143n4a70b259vda1efef8425e4daa at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> Benjamin M. Schwartz writes:
>> There are other options, such as HTML+Javascript, Squeak,
>> and C/C++, but they each suffer from some combination of
>> reduced functionality, problematic cross-platform guarantees,
>> and increased difficulty of programming.
> Let's not ignore Python, which suffers plenty:
> 1. Python has no language standard. The best you can claim is that
>   the language is defined by /usr/bin/python on some random system.
>   There is a history of breaking compatibility with new releases.
>   There exist several Python interpreters actually, which don't
>   run the same code. Python version 3 will probably break your code.
> 2. Python is a joke regarding performance. You know how Java is often
>   several times slower than C? Java beats Python by 20x or 30x.
> 3. Python being easy is **your** opinion. (and you're wrong)
> 4. Python has reduced functionality because it lacks inline assembly.
>   That particular language feature is the door to everything.
> IMHO there is a limit to the value of "universally usable", but if
> you want to push that goal you can. The most stable interfaces are
> the CPU instructions, the Linux system call interface, and the X11
> protocol. Bring along any interpreter you need, and statically link
> all the binary executables. If you need Python 2, include a copy.
> Be sure it doesn't need any /lib/*.so files to run; you can check
> this by running ldd on the binary.
> FWIW, plain C is an excellent choice. It's the easiest language.
> Unless you tolerate FORTRAN or assembly, it's also the fastest.

More information about the IAEP mailing list