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