octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Add min/max tests. (4/4)


From: Edward Jason Riedy
Subject: Re: [PATCH] Add min/max tests. (4/4)
Date: Wed, 13 Sep 2000 18:05:28 -0700

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.
 * The FFI is nice, expecially from C++.
 * More of the people who will use the code I'm writing know
   Python than other full-featured scripting languages. 
 * The implementation is still simple enough for me to twiddle
   without a huge investment.
 * A good deal of effort by others is going into making Python
   easy to use / understand.
 * Introspective enough that I may be able to get a distributed
   version to work.  Maybe.
 * Code looks pretty.

Why other, not entirely dissimilar languages don't immediately 
appeal to me for my current numerical work:
  Dylan:    Unstable implementation I'd have to port myself.  I'd love
            to use a good Dylan, or a Dylan-Python hybrid.
  Erlang:   Nice, but doesn't fit the problem domain.
  Perl:     The FFI is a mess, it's currently experiencing
            Ada-disease, and bad experiences with its development
            process.
  Scheme:   Inherent, mostly unjustified prejudice against it in 
            my target audience.
  CL:       Same.
  ML:       Likewise, plus my general dislike of strict static 
            typing at that level.  Has odd FP operators due to 
            lack of polymorphism in the right places.
  Haskell:  Laziness doesn't mix well with tight memory 
            requirements, and monads are, well, monads.
  APL:      Heh.  Yes, I know APL.
  Lua:      Too little infrastructure in the language.  
  Ruby:     I don't know.  Something about it doesn't feel right.
  Forth, Smalltalk, other one-paradigm-fits-all-languages:
            My main work (parallel, unsymmetric sparse matrix
            factorization and associated problems) doesn't fit
            into a single paradigm sanely.
  Java:     Don't get me started.
  Pike, ElastiC, etc.: 
            If I want C, I'll use C.
  The other 203983792039734920 languages out there:
            No time to learn more right now.
  Matlab-esque: 
            I need a good many general-purpose language features.
            Matlab may have added them, but they feel foreign.

Obviously, many of these reasons are highly subjective.  I'm not 
going to pretend otherwise.

 - 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,
and the license would require my target audience to think
about licensing rather than science.

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.

Jason



reply via email to

[Prev in Thread] Current Thread [Next in Thread]