From octave-maintainers-request at bevo dot che dot wisc dot edu  Wed Sep 13 21:46:09 2000
Subject: Python (was: Re: [PATCH] Add min/max tests. (4/4))
From: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
To: Edward Jason Riedy <ejr at EECS dot Berkeley dot EDU>
Cc: octave-maintainers at bevo dot che dot wisc dot edu
Date: Wed, 13 Sep 2000 21:46:54 -0500 (CDT)

On 13-Sep-2000, Edward Jason Riedy <ejr at EECS dot Berkeley dot EDU> wrote:

| And "John W. Eaton" writes:
|  -
|  - Why Python in particular and not some other scripting language?  
| 
| My reasons:
|  * The core developers have expressed an interest in good
|    (ieee754) fp support.

Where have they expressed this interest?  In the version of Python
that I looked at (1.5.x?), Inf and NaN were not supported very well at
all.  Has the situation changed in any released version of Python?

|  * The FFI is nice, expecially from C++.

Sorry, I'm dense.  What is FFI?

|  * More of the people who will use the code I'm writing know
|    Python than other full-featured scripting languages.

OK.  I believed the same thing about Matlab when I started writing
Octave.  That was the primary reason for choosing the Matlab syntax.
It was not because I really liked it more than anything else.  Now,
after some years of experience, I'm not sure that popularity is a good
reason for choosing a language for the long term.  Short term it is
probably OK, but favor for one language over another tends to shift.

|  * The implementation is still simple enough for me to twiddle
|    without a huge investment.

This will probably change.  The new print>> and op= stuff seems to be
making Python less consistent, which usually means trouble.

Related to the problem of these new operators adding complexity is the
push from some people for new operators for specific numerical tasks.
I'm not sure that is a good idea.  You can't please everyone with a
given set of operators and precedence levels for them.  I don't think
that it is reasonable to expect one language to meet the needs of
everyone.

What would be nice (IMO) is to be able to easily share data between
languages.  One way to do this would be to have a language-neutral
interpreter plus front ends that have syntax and semantics appropriate
for specific problem domains.  Then someone could write numerical code
with nice infix operators and someone else could write AI stuff with
lispy syntax and someone else could write GUI stuff in some OO
friendly syntax.  If this sort of thing has been tried somewhere and
rejected as unworkable, I'd like to know about it.  As it is, we still
seem to be in the one-size-fits-all era of computer language design.

|  * A good deal of effort by others is going into making Python
|    easy to use / understand.

OK.

|  * Introspective enough that I may be able to get a distributed
|    version to work.  Maybe.

I'm not sure I understand what you mean by this.

|  * Code looks pretty.

Quite subjective (as you admit below).

| Why other, not entirely dissimilar languages don't immediately 
| appeal to me for my current numerical work:

I agree with most of your comments here.  I don't understand why there
are so many Lisp/Scheme haters out there.

|  - But if I didn't want Matlab (or Octave), why would I choose
|  - Python?                                            
| 
| To be honest, I'd really love to see a general mathematical         
| library that can be used in many quick-writing languages.  

| Octave's is a bit too tilted towards Matlab's way of thinking,

Can you be more specific?  The stuff in liboctave does have some
features that are there only to support Matlab-like things, but you
are not forced to use them if you want to use liboctave from some
other interpreter.

| and the license would require my target audience to think
| about licensing rather than science.

I also don't want to start a license war, but is the GPL a problem for
you now?  If so, how?

If NumPy were rewritten to use parts of Octave and to avoid some of
the mistakes of Matlab, do you think the average Python user would
object to parts of it being covered by the GPL?

| The library would have to be surprisingly low-level to allow
| each language to layer its own way of thinking on it.  I'm not
| sure how much sense that makes, though.

I think we already have some very low level libraries out there
(blas, lapack, etc.) and they are generally hard to use.  Maybe that
is why there are not interfaces to these libraries for all the popular
scripting languages.  But perhaps you are looking for something at a
slightly higher level, for example, one that doesn't require that you
pass A, LDA, M, and N when you just want to pass a matrix, or one that
doesn't require the programmer to size and pass in work arrays?

jwe