Excellent comments from Jaison and Ryo. Ferret has always been a fantastic and
unique tool for many applications (huge datasets, remote datasets, quick
exploration of NetCDF and OPeNDAP data, regridding, mapping, and anything
requiring calendars, modulo longitude/time axes, and axis-broadcasting), but
clunky for others (complex and iterative programming, element-by-element
indexing, local scope (modules & namespaces), multi-variable returns from
functions, and publication-quality graphics).
But stay tuned! The Ferret developers are working on wrapping the Ferret code
into a Python module, and already have a quite polished working prototype
("Ferret 7") that some of us have been testing. This is a HUGE development for
both the Ferret and Python communities -- it means that we will soon have all of
the above capabilities.
With Ferret7, one can easily switch back and forth between a standard Ferret
environment and a Python prompt, and pass variables between the two. One can
also write scripts in either Ferret or Python, and even switch between languages
inside of a single .jnl file or a single Python script. And Ferret external
functions can be written in Python, or any language that Python wraps --
allowing one to call, for example, any of the routines in NumPy, SciPy, or any
other Python library, and have all of the variable & axis metadata carry through
as we're used to. Karl Smith has already ported many of the scipy.stats
routines -- for finding PDFs and quantile functions, generating random deviates,
parameter fitting, confidence intervals, statistical tests, etc. from a large
number of distributions -- into Ferret external functions, and the results are
impressive. So we will soon be able to access all the power of Ferret, Python,
PCMDI's CDAT, Matlab (via numpy+scipy+matplotlib), and Mathematica/Maple (via
sympy and sage), in one place.
As they always have, the developers have taken care to maintain
backwards-compatibility, so existing Ferret .jnl scripts will all work in
Ferret7. The Ferret prompt and environment are unchanged, and old-timers
needn't even be aware of the Python capability if they don't want to. But my
goodness, if you know or learn Python, you'll now have all the control
structures, object-oriented capability, and vast libraries of Python, including
numerous fonts and 2d & 3d graphics libraries (matplotlib, sage, cdat, ncvtk).
It's exciting to see the future of Ferret!
Andrew
On 09/29/2011 08:23 PM, Ryo Furue wrote:
> Hi,
>
> I agree that there are many problems which Ferret is not a suitable programming language to solve in. Here I'd just like to comment on the following issue.
>
>> 1. Delayed mode evaluation
>> Ferret evaluates all expressions only when it meets an action command (Ch3 Sec2. EXPRESSIONS).
>> This means that you cannot use expressions like
>>
>> let var = var * something_else
>>
>> One may think this is not a serious problem and a new variable name can be used for such steps.
>> But in experience, this is a serious problem.
> That is a problem, for example, when you want to loop. But, lazy evaluation is necessary in Ferret:
>
> let speed = (u*u + v*v)^0.5 ! big 4D arrays
> fill/k=1/l=1 speed ! I only need a slice
>
> Ferret computes only the necessary part of the big array, which is a blessing. In an eager-evaluation language like C and Fortran, the first line would consume a lot of time and memory. You can't do this
>
> let var = var + something
>
> because the (partial) evaluation of the right-hand side occurs only when its value is required. In other words, "let" is a "definition", not an "assignment", in Ferret.
>
> In Ferret, you don't usually use loops; you use functions. In such a case, lazy evaluation saves time and memory because computation occurs only when necessary. (There are computer languages that behave like that; Haskell is a primary example. You don't use loops in such a language; you use functions.)
>
>> Another aspect is that you cannot use a variable
>> name which is already there in any of the opened datasets.
> I think this is a separate issue, and I agree that a fine-grained namespace would be very nice for programming.
>
> Regards,
> Ryo
>