Python for Fortran programmers
beli...@aol.com
value-add
proposition for Python in the Fortran community", which I am reposting
here. He said he wants feeback.
I think a scripting language such as Python is a good complement to a
compiled language such as Fortran or C++, but I would still prefer to
have the "guts" of a computationally intensive program in Fortran,
because of speed, finer control (Fortran KIND's for example), and the
greater number of programming errors that are typically detected by a
good compiler vs. an interpreter.
Here is his essay.
===
The established use of Fortran in continuum models such as climate
models has some benefits, including very high performance and
flexibility in dealing with regular arrays, backward compatibility with
the existing code base, and the familiarity with the language among the
modeling community. Fortran 90 and later versions have taken many of
the lessons of object oriented programming and adapted them so that
logical separation of modules is supported, allowing for more effective
development of large systems. However, there are many purposes to which
Fortran is ill-suited which are increasingly part of the modeling
environment.
These include: source and version control and audit trails for runs,
build system management, test specification, deployment testing (across
multiple platforms), post-processing analysis, run-time and
asynchronous visualization, distributed control and ensemble
management. To achieve these goals, a combination of shell scripts,
specialized build tools, specialized applications written in several
object-oriented languages, and various web and network deployment
strategies have been deployed in an ad hoc manner. Not only has much
duplication of effort occurred, a great deal of struggling up the
learning curves of various technologies has been required as one need
or another has been addressed in various ad hoc ways.
A new need arises as the ambitions of physical modeling increase; this
is the rapid prototyping and testing of new model components. As the
number of possible configurations of a model increases, the expense and
difficulty of both unit testing and integration testing becomes more
demanding.
Fortunately, there is Python. Python is a very flexible language that
has captured the enthusiasm of commercial and scientific programmers
alike. The perception of Python programmers coming from almost any
other language is that they are suddenly dramatically several times
more productive than previously, in terms of functionality delivered
per unit of programmer time.
One slogan of the Python community is that the language "fits your
brain". Why this might be the case is an interesting question. There
are no startling computer science breakthroughs original to the
language, Rather, Python afficionados will claim that the language
combines the best features of such various languages as Lisp, Perl,
Java, and Matlab. Eschewing allegiance to a specific theory of how to
program, Python's design instead offers the best practices from many
other software cultures.
The synergies among these programming modes is in some ways harder to
explain than to experience. The Python novice may nevertheless observe
that a single language can take the place of shell scripts, makefiles,
desktop computation environments, compiled languages to build GUIs, and
scripting languages to build web interfaces. In addition, Python is
useful as a wrapper for Fortran modules, facilitating the
implementation of true test-driven design processes in Fortran models.
Another Python advocacy slogan is "batteries included". The point here
is that (in part because Python is dramatically easier to write than
other languages) there is a very broad range of very powerful standard
libraries that make many tasks which are difficult in other languages
astonishingly easy in Python. For instance, drawing upon the standard
libraries (no additional download required) a portable webserver
(runnable on both Microsoft and Unix-based platforms) can be
implemented in seven lines of code. (See
http://effbot.org/librarybook/simplehttpserver.htm ) Installation of
pure python packages is also very easy, and installation of mixed
language products with a Python component is generally not
significantly harder than a comparable product with no Python
component.
Among the Python components and Python bindings of special interest to
scientists are the elegant and powerful matplotlib plotting package,
which began by emulating and now surpasses the plotting features of
Matlab, SWIG, which allows for runtime interoperability with various
languages, f2py which specifically interoperates with Fortran, NetCDF
libraries (which cope with NetCDF files with dramatically less fuss
than the standard C or Fortran bindings), statistics packages including
bindings to the R language, linear algebra packages, various
platform-specific and portable GUI libraries, genetic algorithms,
optimization libraries, and bindings for high performance differential
equation solvers (notably, using the Argonne National Laboratory
package PetSC). An especially interesting Python trick for runtime
visualization in models that were not designed to support it, pioneered
by David Beazley's SWILL, embeds a web server in your model code.
See especially http://starship.python.net/~hinsen/ScientificPython/ and
http://scipy.org as good starting points to learn about scientific uses
of Python.
Paul Van Delst
> Michael Tobis has posted an essay in comp.lang.python regarding "the
> value-add
> proposition for Python in the Fortran community", which I am reposting
> here. He said he wants feeback.
>
> I think a scripting language such as Python is a good complement to a
> compiled language such as Fortran or C++, but I would still prefer to
> have the "guts" of a computationally intensive program in Fortran,
> because of speed, finer control (Fortran KIND's for example), and the
> greater number of programming errors that are typically detected by a
> good compiler vs. an interpreter.
>
> Here is his essay.
>
> ===
What's his point? "Python is great so let's all use it" ?
He mentioned the things that Fortran is ill-suited for (not actually describing them for
non-CS folks. "distributed control and ensemble management" ?? What does that mean?) but I
didn't see much in his list that is particularly Fortran-specific. I mean, "source and
version control"? What does that have to do with Fortran? You'd have the same issue with
Python; or <insert language of choice>. My experience with source control has been that
the biggest weakness is the people using it (or not as the case may be), not the method
employed.
And there was no analysis of the balance between his mentioned pros (high performance and
flexibility in dealing with regular arrays, backward compatibility with the existing code
base, and the familiarity with the language among the modeling community) and cons (source
and version control and audit trails for runs, build system management, test
specification,etc..) Should we weight them all equally? Should all involved disciplines
weight them the same way?
As to the ad hoc deployment - when you (figuratively) throw 1000's of people together to
work on something (such as a climate model) and those people are spread across the globe,
work for instituitions that typically have very different goals (even *within* agencies),
and are funded based on who-knows-what criteria, and -- assuming the grand master plan
poobah is prescient enough to forsee all the issues that will crop up along the way --
then good luck trying to come up with a plan for "ad-hoc deployment prevention" upon which
everybody involved can agree. More often than not single viewpoints will dominate (Did
somebody say security?)
I absolutely agree with his comments about unit and integration testing. But no real info
was put forth on how Python can help solve this problem. Will python help design the test
parameters and write the test code?
A rather bland series of paragraphs, IMO. It reads like either a) a funding proposal
[hence all the interspersed buzzwords and jargon to make managers get all excited] or b)
an undergraduate CS assignment.
Now, you'll have to excuse me while I go back to studying PHP/MySQL. It's going to solve
all my problems I'm told.... :o)
cheers,
paulv
--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC
Sebastien....@gmail.com
Paul Van Delst a écrit :
> [...]
> I absolutely agree with his comments about unit and integration testing. But no real info
> was put forth on how Python can help solve this problem. Will python help design the test
> parameters and write the test code?
Please have a look at doctest, a Python module for unit testing
included in the
standard lib:
http://www.python.org/pycon/dc2004/papers/4/PyCon2004DocTestUnit.pdf
Far better than xUnit style unit testing IMHO and AFAIK, it has no
equivalent
outside the python world.
Cheers,
SB
Joe Krahn
> Michael Tobis has posted an essay in comp.lang.python regarding "the
> value-add
> proposition for Python in the Fortran community", which I am reposting
> here. He said he wants feeback.
>
> I think a scripting language such as Python is a good complement to a
> compiled language such as Fortran or C++, but I would still prefer to
> have the "guts" of a computationally intensive program in Fortran,
> because of speed, finer control (Fortran KIND's for example), and the
> greater number of programming errors that are typically detected by a
> good compiler vs. an interpreter.
>
I started using Python because many other scientific programmers are
using it. I initially thought of it as just another Perl, but with
cleaner syntax, and slower. Python-philic developers promise that you
will learn to appreciate the syntax rules. However, after using it for
quite a while, I grew to really hate the indentation syntax.
I think that the typical Fortran programmer will feel the same. Python
begins blocks but never ends them with words, only by un-indentation.
The only way to see how many blocks are ending is to find the matching
indent and count intervening indents.
Ruby should be a better fit for the typical Fortran programmer. I am
surprised Ruby is not more the standard scripting language for
scientists. At least some people who know both say that Ruby is better
even though Python is (at least for now) more popular.
However, I have come to the decision that scripts should be for small
tasks, and that any "Application" should be in a compiled language. All
of these multi-language packages a bloated and slow.
Now that Fortran is finally getting a proper C interface for utilizing
things like regex and GUI libraries, and variable-length strings, I
think it is much more worth while for the average Fortran programmer to
develop modern code using Fortran rather than trying to learn Python.
Joe Krahn
Jan Vorbrüggen
> begins blocks but never ends them with words, only by un-indentation.
> The only way to see how many blocks are ending is to find the matching
> indent and count intervening indents.
I have used a language that does that (occam2) extensively, and it's not
a problem - actually, it can make life easier in some respects - but you
need the right tool for the job, in particular a folding editor. If you
use that, such problems just go away.
Jan
Joe Krahn
And then you also need a folding viewer to read code sensibly? To me,
that means that the language syntax really is a deficiency, but you can
offset that deficiency with the "right" tools, which may mean having to
learn to use a different editor than the one you've become used to for
many years.
Also, how can the indentation rules make life easier? The idea of
forcing proper indentation is probably good for making code more
readable, but the how can idea of invisible end-of-block syntax ever be
good? Some people may get used to or even like it, but I think that
programmers who use Fortran a lot are the least likely to be comfortable
with that syntax.
What might be nice is for a language to offer syntax variations to allow
a programmer to pick different block-delimiter styles. I think there is
not much of a language syntax conflict, just a language developer conflict.
Joe Krahn
James Giles
...
> And then you also need a folding viewer to read code sensibly? To me,
I have always thought that if it requires a specialized tool to
read or maintain your program, then either the language or
the program (or both) was poorly designed. This is probably
an old-fashioned view. Having such a tool almost certainly
makes it easier to read even well written code in a well
designed language. Once the crutch is ubiquitous (or,
at least, not rare) no doubt people using poorly designed
languages and writing bad code will consider the deficiencies
irrelevant if the special tool can make up for them.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
Jan Vorbrüggen
>>that means that the language syntax really is a deficiency, [...]
> I have always thought that if it requires a specialized tool to
> read or maintain your program, then either the language or
> the program (or both) was poorly designed. This is probably
> an old-fashioned view. Having such a tool almost certainly
> makes it easier to read even well written code in a well
> designed language. Once the crutch is ubiquitous (or,
> at least, not rare) no doubt people using poorly designed
> languages and writing bad code will consider the deficiencies
> irrelevant if the special tool can make up for them.
In fact, I quite agree with you...but I don't think it applies in this
case.
Let's face it - we write a lot of hierarchically structured documents.
Every time I write a piece of text longer than, say a page, it will be
hierarchically structured - hey, that fairly often even applies to e-mail.
Any F90 program that doesn't fit on a single screen matches as well. And
so on, and so on, ... So why are we still using editors that have no other
view of the document but the single-level sequential one?
And you don't need to use a different editor: emacs, for instance, has a
folding mode you can use.
In this case, I think it's the other way 'round: the traditional way of
doing things is so entrenched that an apporpriate tool - appropriate to
human cognition - is _not_ being used widely.
Jan
Bil Kleb
>
> Now, you'll have to excuse me while I go back to studying PHP/MySQL.
> It's going to solve all my problems I'm told.... :o)
Oh, so they haven't told you about Ruby on Rails? ;)
Bil Kleb
>
> Ruby should be a better fit for the typical Fortran programmer.
I second this hypothesis. Some of our new-to-Ruby developers
write Fortran in Ruby!
(In fact, I managed to get this injected into the new Pragmatic
Bookshelf book I recently reviewed: /Practices of an Agile Developer/,
http://www.pragmaticprogrammer.com/titles/pad/.)
> However, I have come to the decision that scripts should be for small
> tasks, and that any "Application" should be in a compiled language.
While I agree to some extent, the power of using dynamic
languages like Python and Ruby for "gluing together" systems
of high-level components is quite liberating.
> I think it is much more worth while for the average Fortran programmer to
> develop modern code using Fortran rather than trying to learn Python.
It depends what you mean by "learn". Learning the /basic/ constructs
and behavior of a dynamic language like Ruby, for example, can be
grasped in a matter of minutes: http://tryruby.hobix.com/
I have found that learning at least one other language that
is significantly different than your "native" language reaps
many unexpected benefits. You gain not only the new ability
provided by the new language, but also the many lessons and
idioms that you are able to take back to your original one.
Regards,
--
Bil
http://fun3d.larc.nasa.gov
Bil Kleb
>
> I think a scripting language such as Python is a good complement to a
> compiled language such as Fortran or C++, but I would still prefer to
> have the "guts" of a computationally intensive program in Fortran,
> because of speed, finer control (Fortran KIND's for example), and the
> greater number of programming errors that are typically detected by a
> good compiler vs. an interpreter.
Agreed. (Although I prefer the Ruby flavor.) In fact,
I just posted a request for information of sorts along these lines
in news:comp.lang.ruby. (see http://tinyurl.com/7s9zy)
> A new need arises as the ambitions of physical modeling increase; this
> is the rapid prototyping and testing of new model components. As the
> number of possible configurations of a model increases, the expense and
> difficulty of both unit testing and integration testing becomes more
> demanding.
This exactly one of the points I tried to make in my "Scientific
Simulations and the Scientific Method" paper available here,
http://hdl.handle.net/2002/16096
Regards,
--
Bil Kleb
http://fun3d.larc.nasa.gov
Paul Van Delst
Great paper - I'm going to direct colleagues to the link (the guy that wrote the Python
essay that started this thread might want to give it a read too :o). The one thing I'm
still having trouble with is: if you want to component test various modules of a software
package (in my case, all in Fortran95), where does all the Ruby (or Python) stuff come
into it? I mean, what do you actually use Ruby (or Python) for? (Apologies if the question
seems braindead).
I guess I'm looking for a more concrete example closer to my own situation as we're
dealing with these sorts of issues here (in the group I work with). Software updates are
getting further and further apart because the testing schedule (component + regression)
keeps growing. It would be really nice if the testing requirements could be formalised in
such as way so that the individual developers (i.e. scientists) of new stuff (new
algorithms for old data/instruments, or new algorithms to deal with new data/instruments)
are also tasked with testing, but in a way that eases integration.
cheers,
paulv
Bil Kleb
> Bil Kleb wrote:
>> This exactly one of the points I tried to make in my "Scientific
>> Simulations and the Scientific Method" paper available here,
>>
>> http://hdl.handle.net/2002/16096
>
Thanks. We certainly had fun writing and presenting it.
If you liked the style of that one, you might also enjoy:
http://doi.ieeecomputersociety.org/10.1109/MS.2003.1196317
or, an earlier (free) version, http://hdl.handle.net/2002/12649
> The one thing I'm still having trouble with is: if you
> want to component test various modules of a software package (in my
> case, all in Fortran95), where does all the Ruby (or Python) stuff come
> into it? I mean, what do you actually use Ruby (or Python) for?
Got some links (a bit old) for that one too. ;)
http://www.devsource.com/article2/0,1759,1778699,00.asp
http://www-128.ibm.com/developerworks/linux/library/l-oslab/
http://www.rubygarden.org/ruby?WhatDoesNasaUseRubyFor
http://www.rubyquiz.com/quiz46.html
(see also the front page of our FUN3D website)
James Giles
...
> In this case, I think it's the other way 'round: the traditional way
> of doing things is so entrenched that an apporpriate tool -
> appropriate to human cognition - is _not_ being used widely.
Well, I would still say that more important than the tools
are the design of the language and of programs.
However, the tools have a long way to go before they can
beat what I can already do without them. If some part of
the program's text is to be folded, an abstract needs to be
provided in its stead that describes something of what the
invisible code does and the principal variables it operates
on. Well, I can already do that without any special purpose
tool or feature of the editor: I can give a properly nested
part of the code a mnemonic name, and list its principal
variables as its argument list and make it a called procedure.
Depending on how closely bound the code is to the caller, it
may be an internal procedure, a module procedure, or an
independent external procedure. The fact that it's also reusable
is convenient since pure hierarchies are not always the best
way to sort things out after all.
Gary L. Scott
> Joe Krahn wrote:
>
>>
>> Ruby should be a better fit for the typical Fortran programmer.
>
>
> I second this hypothesis. Some of our new-to-Ruby developers
> write Fortran in Ruby!
>
> (In fact, I managed to get this injected into the new Pragmatic
> Bookshelf book I recently reviewed: /Practices of an Agile Developer/,
> http://www.pragmaticprogrammer.com/titles/pad/.)
>
>> However, I have come to the decision that scripts should be for small
>> tasks, and that any "Application" should be in a compiled language.
>
>
> While I agree to some extent, the power of using dynamic
> languages like Python and Ruby for "gluing together" systems
> of high-level components is quite liberating.
I agree that a standard macro language does wonders for programming
efficiency. But it is hardly new. It is entwined in most legacy
operating systems. It is absolutely inescapable on the mainframe. I've
always been disappointed that a suitable one didn't come built into
DOS/Windows (batch files do not qualify). IBM started offering REXX,
but that didn't get far.
>
>> I think it is much more worth while for the average Fortran programmer
>> to develop modern code using Fortran rather than trying to learn Python.
>
>
> It depends what you mean by "learn". Learning the /basic/ constructs
> and behavior of a dynamic language like Ruby, for example, can be
> grasped in a matter of minutes: http://tryruby.hobix.com/
>
> I have found that learning at least one other language that
> is significantly different than your "native" language reaps
> many unexpected benefits. You gain not only the new ability
> provided by the new language, but also the many lessons and
> idioms that you are able to take back to your original one.
>
> Regards,
> --
> Bil
> http://fun3d.larc.nasa.gov
--
Gary Scott
mailto:gary...@ev1.net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
Why are there two? God only knows.
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
Brian Elmegaard
> quite a while, I grew to really hate the indentation syntax.
>
> I think that the typical Fortran programmer will feel the same. Python
Maybe I am not typical. At least I appreciate very much the python
syntax where there are no ugly constructions with #{}:@* used in
cryptic ways, like fortran.
I write fortran with indentation and the end statement is more or less
only needed because fortran requires it. However, I guess a more
popular python would allow the programmer to choose either significant
indentation or begin/end.
> Ruby should be a better fit for the typical Fortran programmer.
But it doesn't look like fortran/python, more like perl/c
> language. All of these multi-language packages a bloated and slow.
That's not what the pythonists claim in c-to-python comparisons.
> Now that Fortran is finally getting a proper C interface for utilizing
> things like regex and GUI libraries, and variable-length strings, I
> think it is much more worth while for the average Fortran programmer
> to develop modern code using Fortran rather than trying to learn
> Python.
This sounds interesting. Where can I learn about it? Does g77/gfortran
have it? Python has never has a gui builder that I found easy to
understand.
--
Brian (remove the sport for mail)
http://www.et.web.mek.dtu.dk/Staff/be/be.html
http://www.rugbyklubben-speed.dk
Richard Maine
> Joe Krahn <kr...@niehs.nih.gov> writes:
>
> > Now that Fortran is finally getting a proper C interface for utilizing
> > things like regex and GUI libraries, and variable-length strings,...
>
> This sounds interesting. Where can I learn about it? Does g77/gfortran
> have it? Python has never has a gui builder that I found easy to
> understand.
The C interface stuff is in f2003. Note that there isn't something
specifically for regex and GUI libraries, but instead there is a
general-purpose C interop facility, which should allow use of C
libraries in general, wih the regex and GUI libraries just used here as
examples.
The variable length strings referred to are, I presume, the allocatable
string length stuff of f2003. There is also the ISO_VARYING_STRING
module, but it doesn't integrate nearly as cleanly with the rest of the
language as allocatable strings do. (And, in particular, it doesn't
integrate at all reasonably with C).
The odds of g77 getting the f2003 C interop stuff are zero, if not less.
First g77 would need modules, as most of the C interop stuff is in an
intrinsic module. That's too major a chunk of f90 to have any chance. I
consider modules to be the major dividing line between f77 and f90
compilers. Many f77 compilers do a few f90 features, but if they don't
do modules, then they miss out on most of f90; and once modules are
done, it ends up making sense to finish off f90 and have a full f90
compiler.
I don't think that gfortran has the C interop stuff yet (though I could
be wrong), but it is certainly plausible that it could come. G95 does
have at least some of it - I haven't sat down and looked to see what
parts might still be missing.
I don't think that any compilers yet do the allocatable string length
thing. It is a step beyond the f95 allocatable TR. It wouldn't be
shocking if some do soon, or even if one does already and I've missed
it.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
Steven G. Kargl
nos...@see.signature (Richard Maine) writes:
> Brian Elmegaard <br...@rkspeed-rugby.dk> wrote:
>
>> Joe Krahn <kr...@niehs.nih.gov> writes:
>>
>> > Now that Fortran is finally getting a proper C interface for utilizing
>> > things like regex and GUI libraries, and variable-length strings,...
>>
>> This sounds interesting. Where can I learn about it? Does g77/gfortran
>> have it? Python has never has a gui builder that I found easy to
>> understand.
>
> The C interface stuff is in f2003. Note that there isn't something
> specifically for regex and GUI libraries, but instead there is a
> general-purpose C interop facility, which should allow use of C
> libraries in general, wih the regex and GUI libraries just used here as
> examples.
>
> I don't think that gfortran has the C interop stuff yet (though I could
> be wrong), but it is certainly plausible that it could come. G95 does
> have at least some of it - I haven't sat down and looked to see what
> parts might still be missing.
Two individuals at LANL have almost completed the C interop stuff
for gfortran (at last report). They are supposedly submitting the
FSF Copyright assignment paperwork and wrapping up some final details.
Perhaps, gfortran will have C interop in a month or two.
Brian Elmegaard
> Two individuals at LANL have almost completed the C interop stuff
> for gfortran (at last report).
Sounds good.
beli...@aol.com
Brian Elmegaard wrote:
> Joe Krahn <kr...@niehs.nih.gov> writes:
>
> > quite a while, I grew to really hate the indentation syntax.
> >
> > I think that the typical Fortran programmer will feel the same. Python
>
> Maybe I am not typical. At least I appreciate very much the python
> syntax where there are no ugly constructions with #{}:@* used in
> cryptic ways, like fortran.
I don't understand your assertion. The characters : and * have special
meaning in Fortran, but I don't recall # { } @ having any.
Richard Maine
I wondered the same. But it seemed such a strange comment that I went
back and relooked to see if I had read it correctly. On about the 3rd or
4th reading, I noticed the comma before "like fortrran". That gave me
the clue. Although I consider the construction slightly cryptic <grin>,
I think he means that python has no stuff used in cryptic ways, just
like fortran has no such stuff used in cryptic ways that is "like
fortran" applies to the "there are no ugly constructions" instead of the
"used in cryptic ways".
I abstain on whether things like Fortran's distinction between : and *
counts as cryptic. :-) I'm just trying to interpret what was written
here.
Richard Steiner
>I don't understand your assertion. The characters : and * have special
>meaning in Fortran, but I don't recall # { } @ having any.
On Unisys 2200 Fortran compilers "@" is to delimit inline comments. :-)
That ain't standard, tho... @ Although it *is* useful
--
-Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Mableton, GA USA
OS/2 + eCS + Linux + Win95 + DOS + PC/GEOS + Executor = PC Hobbyist Heaven!
WARNING: I've seen FIELDATA FORTRAN V and I know how to use it!
The Theorem Theorem: If If, Then Then.
Brian Elmegaard
> I think he means that python has no stuff used in cryptic ways, just
> like fortran has no such stuff used in cryptic ways that is "like
You think rightน.
น You may insert a comma wherever you like.
Jan Vorbrüggen
> beat what I can already do without them. If some part of
> the program's text is to be folded, an abstract needs to be
> provided in its stead that describes something of what the
> invisible code does and the principal variables it operates
> on. Well, I can already do that without any special purpose
> tool or feature of the editor: I can give a properly nested
> part of the code a mnemonic name, and list its principal
> variables as its argument list and make it a called procedure.
Yes about the requirement of describing, in some sense or the other,
what the contents of a fold does.
However, using a folding editor applies this at several below the
modularity you then imply:
> Depending on how closely bound the code is to the caller, it
> may be an internal procedure, a module procedure, or an
> independent external procedure.
For instance, all declarations would be one fold, with subfolds
for the declaration of dummy arguments, local parameters, local
arrays, and local scalars (by way of example). Same principle
applies to the executable statements. This made it possible to
quickly navigate largish pieces of code even on a 24x80 screen.
Jan
me...@skyway.usask.ca
Chris
Bil Kleb
>Joe Krahn writes:
>>Ruby should be a better fit for the typical Fortran programmer.
>
> But it doesn't look like fortran/python, more like perl/c
I find that I can make Ruby code look like anything I would
like, thanks in part to optional ()s, reflection, and not
adhering to Python's OneWayAndOnlyOneWay philosophy.
With Ruby's mandatory ends, for loops, if blocks, and do blocks,
it seems closer to Fortran than say, Python.
As an example, consider the power Ruby has in terms of
creating Domain Specific Languages (DSLs):
http://yhrhosting.com/rubyconf/JimWeirich320.mov (lame video+audio)
http://yhrhosting.com/rubyconf/rc12-sat-aftnoon-jim_weirich.mp3 (decent audio)
Cameron Laird
<Sebastien....@gmail.com> wrote:
.
.
.
>Please have a look at doctest, a Python module for unit testing
>included in the
>standard lib:
>
>http://www.python.org/pycon/dc2004/papers/4/PyCon2004DocTestUnit.pdf
>
>Far better than xUnit style unit testing IMHO and AFAIK, it has no
>equivalent
>outside the python world.
.
.
Another independent alternative to xUnitism comes from the Tcl
world, where testing <URL: http://wiki.tcl.tk/testing > has a
distinguished, even singular, tradition that long antedates
Java, and where co-operation with Fortran <URL:
http://wiki.tcl.tk/fortran > also has been valued for many years.
Cameron Laird
Bil Kleb <Bil....@NASA.gov> wrote:
.
.
.
>While I agree to some extent, the power of using dynamic
>languages like Python and Ruby for "gluing together" systems
>of high-level components is quite liberating.
.
.
There's a project: how do we explain to experienced Fortran
implementers the advantages of test-driven "agile" development
with a dynamic (or, sometimes, weakly-typed) language? From
the other side, I think we also lack a succinct essay on the
limitations of Matlab and friends which "real" programming
languages such as Python (or Lisp or Ruby or ...) overcome.
I've faced the former challenge occasionally over the last
twenty-five years, and it feels past time to settle it more
systematically.
Cameron Laird
Joe Krahn <kr...@niehs.nih.gov> wrote:
.
.
.
>Ruby should be a better fit for the typical Fortran programmer. I am
>surprised Ruby is not more the standard scripting language for
>scientists. At least some people who know both say that Ruby is better
>even though Python is (at least for now) more popular.
.
.
Please help me understand what you're writing here. I *think*
you're saying that Ruby is easier for Fortraneers to learn at
the syntactic level than Python. I can well imagine that.
There's a distinct meaning of "better fit", though, that I want
to highlight. I propose that Python has established its "fitness"
through the record of successful projects implemented as
Python-Fortran *collaborations*. There are several aspects to
these realizations of partnerships between a couple of different
languages:
A. It might well be that two languages need a little
distance between themselves syntactically to
"marry" well; if they're too similar at this level,
there's no gain to a division of labor between
them.
B. Python has a strong tradition of "playing nicely"
with outside resources. It was one of Python's
prominent initial goals, back at its invention in
the late '80s. Ruby also aims to do better at
this than, for example, Perl, but, as near as I
can tell, the Ruby community has never emphasized
cooperation with other languages as much as have
Pythonistas.
C. At a technical level, I believe it remains easier
to bind Python and Fortran than to do so with Ruby
and Fortran.
My conclusion: there are valid reasons, beyond "popularity", to
fit Python and Fortran together.
Cameron Laird
>and behavior of a dynamic language like Ruby, for example, can be
>grasped in a matter of minutes: http://tryruby.hobix.com/
>
>I have found that learning at least one other language that
>is significantly different than your "native" language reaps
>many unexpected benefits. You gain not only the new ability
>provided by the new language, but also the many lessons and
>idioms that you are able to take back to your original one.
.
.
Yes and no. I ENTIRELY agree that there's a population of Fortran
programmers who don't realize how little they need invest to learn
the rudiments of a different, but significant, language. A few
*minutes* with "try ruby!" or comparable facilities for Tcl, Python,
Perl, ... can yield a feel for those languages that they might
anticipate after only hours or days of effort; their basic operation
is that much "friendlier" than experience with Fortran or Java or
... would lead one to expect.
I also strongly urge learning multiple languages as a mind-expanding
exercise <URL: http://www.unixreview.com/documents/s=10013/ur0602i/ >;
one does indeed learn "lessons and idioms". I'm a bit wary, though,
about so counseling a working scientist or engineer whose only regard
for Fortran is as a tool. Without peers to help his critical under-
standing of the new idioms through active review, I suspect the return
on his investment will be diffuse and low.
So: learn another language, and you'll understand Fortran better; but
be aware that there's a bit of an 'S' in the investment-return curve,
and you'll probably find the most satisfaction only if you pick up the
second language more profoundly than as a dilettante.
tooper
or prototyping, but components are better checked / faster executed /
more safely versionned in a (close linked) compiled module.
I guess this is also exactly why I'd for the moment prefer Python to
Ruby to glue things : as a gluing language, I'm more interested in the
"gluing capability" than in the language syntax itself (anyway I'll
just have small bits of it !). And for the moment, there are far more
packages available in Python to connect to almost everything than they
are in Ruby...
Cameron Laird
Gary L. Scott <gary...@ev1.net> wrote:
.
.
.
>DOS/Windows (batch files do not qualify). IBM started offering REXX,
>but that didn't get far.
.
.
Ouch! From *my* perspective, Rexx has indeed come quite a long way
<URL: http://www.unixreview.com/documents/s=9953/ur0601h/ >. Maybe
you had different expectations for it than I ... In any case, I
think it's worth making the point here that Rexx is very much a
language of the present, and apt for Windows and Unix hosts; it's
in no way restricted to mainframes, as your remarks might lead a
naive reader to suspect. I do agree that Rexx doesn't play the
role with Windows that it had with OS/2 and CMS and ...
Cameron Laird
And DSLs--there needs to be an explanation of DSLs somewhere in there.
Cameron Laird
Bil Kleb <Bil....@NASA.gov> wrote:
>Paul Van Delst wrote:
.
.
.
>> The one thing I'm still having trouble with is: if you
>> want to component test various modules of a software package (in my
>> case, all in Fortran95), where does all the Ruby (or Python) stuff come
>> into it? I mean, what do you actually use Ruby (or Python) for?
>
>Got some links (a bit old) for that one too. ;)
>
> http://www.devsource.com/article2/0,1759,1778699,00.asp
> http://www-128.ibm.com/developerworks/linux/library/l-oslab/
> http://www.rubygarden.org/ruby?WhatDoesNasaUseRubyFor
> http://www.rubyquiz.com/quiz46.html
> (see also the front page of our FUN3D website)
.
.
I think there's more to say (and thanks, by the way, for the
advertisement--the l-oslab reference above). We still need
to write an explanation aimed at Fortran programmers of
exactly why test composition is more productive in a high-
level language.
One approach is to ask why people don't write unit tests in
Fortran (in fact, some do; as it happens, the very first
program I wrote for an electronic computer was in FORTRAN,
and unit-tested trigonometric results). Somehow, it feels
ardurous; in a dynamic language, though, a test collection
can be as simple and easily maintained as
do_test attach-1.4 {
execsql {
SELECT * FROM t2;
}
} {1 x 2 y}
do_test attach-1.5 {
execsql {
DETACH DATABASE two;
SELECT * FROM t1;
}
} {1 2 3 4}
do_test attach-1.6 {
catchsql {
SELECT * FROM t2;
}
} {1 {no such table: t2}}
This is a tiny segment of the massive automated Tcl-coded
testing the remarkable sqlite distribution builds in.
Eventually, I'd like to get permission to write about some
of the tests I've written for engineering projects. There's
an important question here, and I think we can answer it
better.
Phil Tomson
>In article <y7QIf.39$9r...@mencken.net.nih.gov>,
>Joe Krahn <kr...@niehs.nih.gov> wrote:
> .
> .
> .
>>Ruby should be a better fit for the typical Fortran programmer. I am
>>surprised Ruby is not more the standard scripting language for
>>scientists. At least some people who know both say that Ruby is better
>>even though Python is (at least for now) more popular.
> .
> .
> .
>Please help me understand what you're writing here. I *think*
>you're saying that Ruby is easier for Fortraneers to learn at
>the syntactic level than Python. I can well imagine that.
>
>There's a distinct meaning of "better fit", though, that I want
>to highlight. I propose that Python has established its "fitness"
>through the record of successful projects implemented as
>Python-Fortran *collaborations*.
This is because Python was there earlier.
> There are several aspects to
>these realizations of partnerships between a couple of different
>languages:
>A. It might well be that two languages need a little
> distance between themselves syntactically to
> "marry" well; if they're too similar at this level,
> there's no gain to a division of labor between
> them.
Maybe so, but I don't see how Ruby is anymore Fortran-like than Python ;-)
>B. Python has a strong tradition of "playing nicely"
> with outside resources. It was one of Python's
> prominent initial goals, back at its invention in
> the late '80s. Ruby also aims to do better at
> this than, for example, Perl, but, as near as I
> can tell, the Ruby community has never emphasized
> cooperation with other languages as much as have
> Pythonistas.
>C. At a technical level, I believe it remains easier
> to bind Python and Fortran than to do so with Ruby
> and Fortran.
There are lots of tools like the dl library, Inline::C (Inline::Fortran
coming?) available in Ruby as well. I forget the details, but didn't someone
earlier in this thread successfully create a Ruby<->Fortran bridge ?
Phil
Bil Kleb
> I fully support the idea that scripting languages are good for gluing
> or prototyping, but components are better checked / faster executed /
> more safely versionned in a (close linked) compiled module.
Our F90 unit testing framework, simply extends Fortran with
some unit-test-specific keywords and macros that get turned
into valid Fortran. For example, a unit test may look like
integer, dimension(8) :: dateAndTime1, dateAndTime2
real :: seconds
beginSetup
NotInitialized = .TRUE.
last = 0
seconds = HUGE(0.0)
endSetup
beginTest SystemDateAndTimeWorks
call date_and_time(values=dateAndTime1)
IsTrue( dateAndTime1(1) /= -huge(0) )
IsTrue( size(dateAndTime1,1) == 8 )
endTest
The framework unrolls this into valid Fortran complete
with a test runner that handles compilation, linking,
error counters, setups, teardowns, etc.
From the sound of it, we really need to write this thing
up and get it out the door. I mentioned this back in 2001
and 2002,
http://tinyurl.com/zbhr7
http://tinyurl.com/f2v6q
but no one showed any interest at the time; so I didn't
fight the bureaucracy to get it out the door. Currently,
it comes as part of the FUN3D code (see below), but you
need to be a "U.S. Person" to get a copy of FUN3D.
> And for the moment, there are far more
> packages available in Python to connect to almost everything than they
> are in Ruby...
That moment may have already passed in some areas, at
least in terms of quality as opposed to quantity.
Paul Van Delst
> From the sound of it, we really need to write this thing
> up and get it out the door. I mentioned this back in 2001
> and 2002,
>
> http://tinyurl.com/zbhr7
> http://tinyurl.com/f2v6q
>
> but no one showed any interest at the time; so I didn't
> fight the bureaucracy to get it out the door. Currently,
> it comes as part of the FUN3D code (see below), but you
> need to be a "U.S. Person" to get a copy of FUN3D.
Hmm. Does that include a "person" who happens to live and work in the "U.S." ?
:o)
Joe Krahn
> In article <y7QIf.39$9r...@mencken.net.nih.gov>,
> Joe Krahn <kr...@niehs.nih.gov> wrote:
> .
> .
> .
>
>>Ruby should be a better fit for the typical Fortran programmer. I am
>>surprised Ruby is not more the standard scripting language for
>>scientists. At least some people who know both say that Ruby is better
>>even though Python is (at least for now) more popular.
>
> .
> .
> .
> Please help me understand what you're writing here. I *think*
> you're saying that Ruby is easier for Fortraneers to learn at
> the syntactic level than Python. I can well imagine that.
language itself, not the availability of existing scientific software or
ability to inter-operate with Fortran code.
I personally find the syntax more annoying than even Perl or
fixed-format Fortran. I have a strong feeling that people who are
primarily Fortran programmers will feel the same.
I don't know the details about the history of Python or Ruby, but I have
had the feeling that Python/Fortran work well together simply because
some scientific programmers who were interested in both got them working
well together. More people interested because the interface tools are
there, not because they think Python is good. Maybe they would prefer
Ruby, but they are stuck with Python because the groundwork is there.
So, my idea is that Ruby itself is a better language than Python for a
Fortran programmer, but Python is more capable at working with Fortran
simply because the interfacing tools are there.
>
> There's a distinct meaning of "better fit", though, that I want
> to highlight. I propose that Python has established its "fitness"
> through the record of successful projects implemented as
> Python-Fortran *collaborations*. There are several aspects to
> these realizations of partnerships between a couple of different
> languages:
> A. It might well be that two languages need a little
> distance between themselves syntactically to
> "marry" well; if they're too similar at this level,
> there's no gain to a division of labor between
> them.
Only the functionality really needs to be different. This inherently
affects some parts of the syntax, but not all of it, and certainly not
the [insane to some people] Python indentation rules.
> B. Python has a strong tradition of "playing nicely"
> with outside resources. It was one of Python's
> prominent initial goals, back at its invention in
> the late '80s. Ruby also aims to do better at
> this than, for example, Perl, but, as near as I
> can tell, the Ruby community has never emphasized
> cooperation with other languages as much as have
> Pythonistas.
OK, maybe Ruby+Fortran really is harder to implement due to Ruby's
design, and not just because some Python people did it first.
> C. At a technical level, I believe it remains easier
> to bind Python and Fortran than to do so with Ruby
> and Fortran.
>
> My conclusion: there are valid reasons, beyond "popularity", to
> fit Python and Fortran together.
My point is that Python may not really be the best choice, but
popularity by the right group of scientific developers has made it more
capable. But, perhaps Python really is better than Ruby at binary
language interfacing.
Actually, what I would really like to see is an option for Python to
allow a different set of blocking rules. It seems that what makes good
block-syntax depends a LOT on individual brain function, yet the leaders
of every language seem to think that their ideas are simply better, and
ideas to the contrary are mutiny.
Wouldn't it be nice if Python programmers could write C with indentation
blocking? Unfortunately, suggesting such ideas among the languages
developers only starts arguments. Or, they say: if you don't like it,
don't use Python. But, what if I am only using Python because of the
existing resources in scientific Python? I am just stuck using a syntax
that I hate. Sadly, the benefit of a scripting language is that you
trade off speed for being easier to use. So why use Python at all? F2003
will make it possible to do a lot more in Fortran without the slowdown
and bloat of a scripting language.
So ,my current opinion is that maybe a long-time Fortran programmer is
better off with F2003 than learning a language as different as Python is.
Sorry for ranting a bit, but I'm trying to give you complete view of my
Python opinion. Maybe there are enough people interested in Python but
hate the indentation syntax to make an alternative via a preprocessor. I
just don't know how well it can work if the core language developers are
so strongly against the idea. What do you think? I would even be willing
to put some effort into it if I thought it could go somewhere.
Joe
Joe Krahn
...
>>There are several aspects to
>>these realizations of partnerships between a couple of different
>>languages:
>>A. It might well be that two languages need a little
>> distance between themselves syntactically to
>> "marry" well; if they're too similar at this level,
>> there's no gain to a division of labor between
>> them.
>
>
> Maybe so, but I don't see how Ruby is anymore Fortran-like than Python ;-)
>
> Phil
Ruby has code blocks that are much more like Fortran. Every block has a
visible beginning and end. Python uses (invisible) whitespace. Some
people think it makes sense.
Why does a Python indent always count as one begin-block, but dedents
[un-indents] can be any number? Why not have multiple indents like this,
where CODE is double-indented, and UNTIL is a loop with a condition at
the end of an iteration:
...
IF (condition)
CODE
UNTIL (condition)
...
which means:
...
IF (condition) THEN
DO
CODE
UNTIL (condition)
END IF
...
If Python did that, then indents would be ambiguous. Right now, only
dedents are ambiguous. Oh, maybe with "the right editor", but a lanugage
that claims being easy to read as a major feature should be readable on
a static web page, for example.
To me, a very simple improvement for Python would be to disallow
consecutive dedents, even if only a comment is used. Them, at least
every end-block would be clearly visible, even though it is just whitespace.
Joe
Gary L. Scott
I only meant that Rexx isn't as ubiquitous or popular on the most common
platforms as I would have preferred. OS' should provide one or more
standard, well-featured interpreters as part of the OS product. I don't
like everything about Rexx, but there is a lot to like and I've used it
since it was first introduced at our site in the early to mid 80's. On
the other hand, I've found very little to like about Perl, Tcl, Awk,
Expect which are more pervasive. I've never used Python or Ruby.
Helge Avlesen
> I personally find the syntax more annoying than even Perl or
> fixed-format Fortran. I have a strong feeling that people who are
> primarily Fortran programmers will feel the same.
I don't. I agree python indentation rules can be a bit cumbersome with
a "dumb" editor, but with emacs in python mode this is simply not a
problem.
I have looked a bit at Ruby, but I fail to see why it is supposed to
be superiour to python, at least in the "matlab replacement" sense.
How is the support for (fast) multi dimensional arrays? I have
looked at Narray, but that looks like a one man project and the syntax
looks a bit alien for a fortraner like me compared to numeric python.
What high quality graphics libraries like pygist
(http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/software/python/pygist.html)
or matplotlib (http://matplotlib.sourceforge.net/) are available? can
Ruby wrap Fortran code as easy as f2py
(http://cens.ioc.ee/projects/f2py2e/)? Does ruby have as comfortable
a command line as Ipython (http://ipython.scipy.org/) ? From what I
see Ruby is no match to Python for scientific computing.
Helge
Bil Kleb
>
> So, my idea is that Ruby itself is a better language than Python for a
> Fortran programmer, but Python is more capable at working with Fortran
> simply because the interfacing tools are there.
The interfacing tools are available in Ruby, but folks have yet
to push them into Fortran. As a result of this thread, one of
the Ruby uber Geeks, as made an offer to help bridge this gap if
a Fortran expert is willing. See,
and
http://www.rubygarden.org/ruby?RubyFortran
Michael Prager
>>DOS/Windows (batch files do not qualify). IBM started offering REXX,
>>but that didn't get far.
> .
>Ouch! From *my* perspective, Rexx has indeed come quite a long way
><URL: http://www.unixreview.com/documents/s=9953/ur0601h/ >. Maybe
>you had different expectations for it than I ... In any case, I
>think it's worth making the point here that Rexx is very much a
>language of the present [...]
Rexx has one nasty Catch-22. I used Rexx happily on IBM
mainframes & then on OS/2 and Windows. My needs are not
tremendously sophisticated; mainly scripting involving file and
text manipulations. What made me ultimately prefer Python was
that many of the things I wanted to do involved the filesystem,
and if memory serves, all those functions are external to Rexx
and provided by different vendors as different extensions on
different platforms. IBM Rexx, Regina Rexx, and Personal Rexx
all had different calls and syntax. So it was not trivial to
move from platform to platform, unless I could be sure I had the
same vendor's implementation on each.
After rewriting utility scripts several times as I moved from
platform to platform, it was a relief to find that Python
includes these things in the basic distribution and hides the
differences from the user. It doesn't hurt that it's free, so
when I need to use a remote supercomputer, e.g., I can install
the latest version of Python and run the scripts, unchanged,
that I have tested on my PC.
That does not take away from the excellence of what is standard
in Rexx. I really liked it as a scripting language, and if it
didn't have that particular quirk, I might still be using it.
--
Mike Prager, NOAA, Beaufort, NC
Address spam-trapped; remove color to reply.
* Opinions expressed are personal and not represented otherwise.
* Any use of tradenames does not constitute a NOAA endorsement.
Cameron Laird
>> distance between themselves syntactically to
>> "marry" well; if they're too similar at this level,
>> there's no gain to a division of labor between
>> them.
>Only the functionality really needs to be different. This inherently
>affects some parts of the syntax, but not all of it, and certainly not
>the [insane to some people] Python indentation rules.
.
.
Yeah.
That is, while I continue to believe that what I wrote is
factual, for thinking about Ruby-Python-Fortran comparisons,
it can be at most of tertiary importance. As interesting as
explorations of syntax and semantics can be, they're really
not the point for this thread--you're right.
Cameron Laird
>allow a different set of blocking rules. It seems that what makes good
>block-syntax depends a LOT on individual brain function, yet the leaders
>of every language seem to think that their ideas are simply better, and
>ideas to the contrary are mutiny.
>
>Wouldn't it be nice if Python programmers could write C with indentation
>blocking? Unfortunately, suggesting such ideas among the languages
>developers only starts arguments. Or, they say: if you don't like it,
>don't use Python. But, what if I am only using Python because of the
>existing resources in scientific Python? I am just stuck using a syntax
[maybe F2003
beats everything]
.
.
>Sorry for ranting a bit, but I'm trying to give you complete view of my
>Python opinion. Maybe there are enough people interested in Python but
>hate the indentation syntax to make an alternative via a preprocessor. I
>just don't know how well it can work if the core language developers are
>so strongly against the idea. What do you think? I would even be willing
>to put some effort into it if I thought it could go somewhere.
>
>Joe
'Isn't going to happen.
I'll be more precise: it's a good question. There's
NOTHING wrong with asking it. What I can report, though,
is that it's come up *many* times in the past, and the
core Python maintainers have essentially zero interest in
it.
On the other hand, the same group also thought that JPython,
the Python implementation in Java, was a mistake, and that's
turned out remarkably well. There *are* a few other people
who've already experimented with preprocessing Python in the
way you describe. All it would take is one committed and
capable enthusiast to make this a reality. If you want to
pursue this, I'll help put you in contact with the folks who
have worked on it before.
I have no affection for the idea myself. For me personally,
Python syntax is fine.
Cameron Laird
>trade off speed for being easier to use. So why use Python at all? F2003
>will make it possible to do a lot more in Fortran without the slowdown
>and bloat of a scripting language.
>
>So ,my current opinion is that maybe a long-time Fortran programmer is
>better off with F2003 than learning a language as different as Python is.
.
.
Is Fortran for you all about speed of execution?
I take seriously the "F2003 for everything" proposition. I
don't believe it yet, but I'm thinking about it.
Here are concrete examples of issues I have:
A. Calculation of vibrational modes in satellites:
I reach for a dynamic language to paste together
a variety of algorithms coded in C or C++ or Fortran.
Given a collection of such building blocks, I
haven't figured out a convenient way to use C or
Fortran of assembling them into an application
that gives useful results; I end up fighting
type conflicts, fussing with memory allocation
and string manipulation, and so on. Yes, I
actually have good ways to do strings and
memalloc and such in Fortran nowadays, but they're
so much easier for me in dynamic languages, which
coincidentally let me interact far more dynamically
with partial calculations.
B. Real-time GIS: I have a couple of projects in this
area with serious efficiency constraints. Again,
though, we're putting C++ together with high-level
languages. We're doing novel work, and we need a
lot of interactivity and flexibility as we experiment
with new algorithms.
These are all things I *could* do in pure Fortran (and I have done
similar sorts of things so in the past). I find our teams much more
productive "gluing" in "scripting" languages, though.
I just realized that perhaps you're thinking of the alternatives for
a projects as:
I. Code everything in Fortran;
II. Code everything in Ruby.
That's not my approach AT ALL. I'm arguing for partnership between
languages.
Joe Krahn
something different would be an uphill battle.
>
> On the other hand, the same group also thought that JPython,
> the Python implementation in Java, was a mistake, and that's
> turned out remarkably well. There *are* a few other people
> who've already experimented with preprocessing Python in the
> way you describe. All it would take is one committed and
> capable enthusiast to make this a reality. If you want to
> pursue this, I'll help put you in contact with the folks who
> have worked on it before.
>
> I have no affection for the idea myself. For me personally,
> Python syntax is fine.
Maybe a Python indentation alternative would not be so disliked, if
given a useful example. When you tell a Python-phile you don't like the
indentation syntax, they assume it means that you want bracketing with
braces and hate enforced indentation. That's not my complaint at all. My
only major gripe is the allowance of multiple obscure dedent 'tab stops'
whose width can vary depending on the programmer, and can be hard to
visualize without the 'right editor'.
I have come to realize that many proficient programmers think that some
style rules are inherently superior, and that other people would realize
that if only they tried it for a while. Arguments about brace
indentations in C-style languages will never be resolved. Some people
need to see matching braces at the same indentation level, while other
people only want the indentation level to match. Python gets rid of
brace-style arguments, but then you just get indentation arguments:
all-tab indentation could be a big improvement, but mixing tabs+spaces
is a major hassle.
Why can't all sides see that certain style rules are individual
preferences? It's like dancer saying that everyone can be a good dancer
if they would just give it a try.
Joe
Joe Krahn
> In article <um4Nf.61$9r...@mencken.net.nih.gov>,
> Joe Krahn <kr...@niehs.nih.gov> wrote:
> .
> .
> .
>
>>that I hate. Sadly, the benefit of a scripting language is that you
>>trade off speed for being easier to use. So why use Python at all? F2003
>>will make it possible to do a lot more in Fortran without the slowdown
>>and bloat of a scripting language.
>>
>>So ,my current opinion is that maybe a long-time Fortran programmer is
>>better off with F2003 than learning a language as different as Python is.
>
> .
> .
> .
> Is Fortran for you all about speed of execution?
>
> I take seriously the "F2003 for everything" proposition. I
> don't believe it yet, but I'm thinking about it.
>
would actually prefer "C++ for everything", but that is a difficult
route for someone who does not want to focus a lot of time on computer
science. It's extensibility is a major advantage, but also a major
disadvantage because it has been extended in so many different ways, it
is often hard to make use of existing resources.
> Here are concrete examples of issues I have:
> A. Calculation of vibrational modes in satellites:
> I reach for a dynamic language to paste together
> a variety of algorithms coded in C or C++ or Fortran.
> Given a collection of such building blocks, I
> haven't figured out a convenient way to use C or
> Fortran of assembling them into an application
> that gives useful results; I end up fighting
> type conflicts, fussing with memory allocation
> and string manipulation, and so on. Yes, I
> actually have good ways to do strings and
> memalloc and such in Fortran nowadays, but they're
> so much easier for me in dynamic languages, which
> coincidentally let me interact far more dynamically
> with partial calculations.
I am hoping that F2003 can fix a lot of this hassle, with improved
string support, the ability to sub-class types, and object destructors.
There are no defined constructors, but you can always write one. This is
often better than C++ new, which is not allowed to fail.
> B. Real-time GIS: I have a couple of projects in this
> area with serious efficiency constraints. Again,
> though, we're putting C++ together with high-level
> languages. We're doing novel work, and we need a
> lot of interactivity and flexibility as we experiment
> with new algorithms.
>
> These are all things I *could* do in pure Fortran (and I have done
> similar sorts of things so in the past). I find our teams much more
> productive "gluing" in "scripting" languages, though.
>
> I just realized that perhaps you're thinking of the alternatives for
> a projects as:
> I. Code everything in Fortran;
> II. Code everything in Ruby.
> That's not my approach AT ALL. I'm arguing for partnership between
> languages.
I'm thinking more along the lines of pasting C, C++, Fortran together
with C, and leaving scripting languages for utility stuff like shuffling
data files. Keeping the main "Engine" code all compiled also makes
parallel execution easier (right?). Even if you do use scripting
languages, I think efficient C++/Fortran2003 interaction is more
valuable than a script-language middle man.
Along those lines, I have done some initial work using SWIG to interface
Fortran to C++, but I am considering whether it it best to wait for
F2003, or get a working F95 version done.
I think we also want Fortran2003 callable from C/C++, which requires a
F2003 parser. I have one partly built using Perl Parse::Yapp, which
seems not all that difficult if the lexer gets feedback from the parser.
Joe
Bil Kleb
> I'm arguing for partnership between languages.
As would I, if I was arguing. :)
Michael Wild
> Bil Kleb wrote:
>
>> Joe Krahn wrote:
>>
>>>
>>> Ruby should be a better fit for the typical Fortran programmer.
>>
>>
>>
>> write Fortran in Ruby!
>>
>> (In fact, I managed to get this injected into the new Pragmatic
>> Bookshelf book I recently reviewed: /Practices of an Agile Developer/,
>> http://www.pragmaticprogrammer.com/titles/pad/.)
>>
>>> However, I have come to the decision that scripts should be for small
>>> tasks, and that any "Application" should be in a compiled language.
>>
>>
>>
>> While I agree to some extent, the power of using dynamic
>> languages like Python and Ruby for "gluing together" systems
>> of high-level components is quite liberating.
>
>
> efficiency. But it is hardly new. It is entwined in most legacy
> operating systems. It is absolutely inescapable on the mainframe. I've
> always been disappointed that a suitable one didn't come built into
> but that didn't get far.
>
>
>>
>>> programmer to develop modern code using Fortran rather than trying to
>>> learn Python.
>>
>>
>>
>> It depends what you mean by "learn". Learning the /basic/ constructs
>> and behavior of a dynamic language like Ruby, for example, can be
>> grasped in a matter of minutes: http://tryruby.hobix.com/
>>
>> I have found that learning at least one other language that
>> is significantly different than your "native" language reaps
>> many unexpected benefits. You gain not only the new ability
>> provided by the new language, but also the many lessons and
>> idioms that you are able to take back to your original one.
>>
>> --
>> Bil
>> http://fun3d.larc.nasa.gov
>
>
>
concerning the windows part: in the new .net framework there's a new
shell available, scriptable in c#, with the whole of .net 2 at your
disposal. that should certainly improve the usability of windows for
non-office useres...
michael
mto...@gmail.com
to me or a response on the original newsgroup might have actually
allowed it all to feed back more efficiently.
thanks
mt
mto...@gmail.com
group at NCAR as to how Python might assist their operation.
> What's his point? "Python is great so let's all use it" ?
Exactly!
The point of the essay is that Python can do just about everything
outside the HPC. This means that we have only a single learning curve
to climb outside that of our chosen HPC language, rather than a
plethora of tools. It's also a curve that's easy to climb, and one
which carries huge benefits, benefits which are hard to explain but
easy enough to experience. This is simply a first attempt at explaining
them.
By the way, I am very much interested in exploring how much of the HPC
itself can be moved to Fortran; most of my research is focused on this
precise question. My motivation is summed up in another Python slogan,
"readability counts". It turns out to count more than one might expect,
> didn't see much in his list that is particularly Fortran-specific.
Agreed. This all applies equally to other high performance computing,
which in practice probably amounts to Fortran and C++. I was simply
responding to a request for an explanation from a Fortran shop, and
from the HPC group with which I am most familiar.
> And there was no analysis of the balance between his mentioned pros (high performance and
> flexibility in dealing with regular arrays, backward compatibility with the existing code
> base, and the familiarity with the language among the modeling community) and cons (source
> and version control and audit trails for runs, build system management, test
> specification,etc..) Should we weight them all equally? Should all involved disciplines
> weight them the same way?
Of course not.
This really misses my point. I am not trying to talk you into
abandoning your code base. (Yet, anyway!) I am pointing out that you do
a lot of stuff that is outside that code base, and you could do ALL of
it on a single uniform, well-designed and surprisingly powerful
platform. This reduces your pre and post processing overhead. It also
makes it easier for you to contribute your efforts to reuse by other
scientific communities.
...
> good luck trying to come up with a plan for "ad-hoc deployment prevention" upon which
> everybody involved can agree.
I don't have a "plan", I have found a tool.
There is no suggestion that people should be "prevented" from doing
anything at all, and any such paraphrase strikes me as unfair.
There is only a suggestion that YOU could get YOUR work done better and
faster if YOU use the tool. My motivation is simply that the more
people use the tool, the more people contribute to the tool, and the
better the tool gets. This increases the amount of science we, the
users of this tool, can get done per unit of pain. I'm not trying to
legislate. I'm trying to help.
> But no real info
> was put forth on how Python can help solve this problem. Will python help design the test
> parameters and write the test code?
No, of course we still need to think. Python just makes it an order of
magnitude easier to write the test harness and use it. Which means in
practice that one is more likely to actually get around to doing it,
rather than just talking about it.
mt
mto...@gmail.com
I am astonished at how much discussion this trivial point raises. Like
many Python users, I think it is a clever innovation rather than a
misfeature. I believe that the objection must be raised by people who
have not taken the time to figure out how to get their source editor to
indent or outdent marked blocks, which would mean people who never got
sufficiently serious about Python to understand its value add.
(If you hate it so much it should be an almost trivial matter to write
a preprocessor to convert from a brace style to an indent style block
and back, so you can look at the source however you please. This is a
fine exercise for someone learning a dynamic language, and a perfect
example of the sort of tool that would be so difficult to implement in
Fortran that no one would contemplate it.)
mt
mto...@gmail.com
has a useful place in your code's runtime depends very much on how that
code is structured. At present Python cannot appear in the perfromance
critical loops, except perhaps in rapid prototyping.
There are very talented people claiming that this speed difference can
be removed, but that is not something that will happen in the near
term. (see http://codespeak.net/pypy/dist/pypy/doc/news.html )
It is interesting to note how long it takes promised features to arrive
in Fortran vs Python by the way. Features in next summer's release of
Python weren't even conceved in 2003, yet the implementation of F03
features remains hypothetical.
That said, I eagerly await a Fortran with a C interoperability mode,
because Python is implemented (usually) as a perfectly ordinary piece
of C code, so with F03, Python/Fortran interoperability will return to
the level it has with F77 codes.
mt
Bil Kleb
>>However, after using it for quite a while, I grew to really hate the indentation syntax.
>
> I am astonished at how much discussion this trivial point raises.
Based on the bandwidth generated by it, it exceeded "trivial"
long ago.
Bil Kleb
>
> [..] the
> greater number of programming errors that are typically detected by a
> good compiler vs. an interpreter.
From what I have heard reported from the troops that have
"been there", the lion's share of the errors have nothing
to do with compilers detecting errors or the benefits of
type checking.
Bil Kleb
>
> No, of course we still need to think. Python just makes it an order of
> magnitude easier to write the test harness and use it.
For instance we wrote such a test harness in Ruby (similar to Python)
in 414 lines of code. (I finally initiated the release process
this morning since there seems to be interest.)
mto...@gmail.com
"moved to Fortran".replace("Fortran","Python")
mt
(thanks Cameron!)
Cameron Laird
<mto...@gmail.com> wrote:
.
.
.
>That said, I eagerly await a Fortran with a C interoperability mode,
>because Python is implemented (usually) as a perfectly ordinary piece
>of C code, so with F03, Python/Fortran interoperability will return to
>the level it has with F77 codes.
>
>mt
>
... or, the VMS troglodytes remember, what was common in 1985.
Brian Elmegaard
> 'Isn't going to happen.
I guess any programmer might use his own coding convention and insert
special comments. There is already the special comment for setting the
coding system.
To me the following look very similar. I don't see how ruby would be
more like fortran. I would like to see a comparison, though.
for i in range(10):
#begin
print i
if i>5: break
#end
print i*i
program ii
integer i
do i=0,10
print*,i
if (i.gt.5) goto 1
enddo
1 print*,i*i
end
regards,
--
Brian (remove the sport for mail)
http://www.et.web.mek.dtu.dk/Staff/be/be.html
http://www.rugbyklubben-speed.dk
Jan Vorbrüggen
> perfect example of the sort of tool that would be so difficult to implement
> in Fortran that no one would contemplate it.)
Hugh? Done a lot of such things in Fortran, what's so difficult about it?
Jan
beli...@aol.com
In the book "Software Tools" (1976), Kernighan and Plauger wrote a
preprocessor in FORTRAN IV to convert from Ratfor (Rational Fortran),
which looks like C, to Fortran IV.
A similar book is "FORTRAN Tools for VAX/VMS and MS-DOS" by Russell K.
Jones and Tracy Crabtree (1988).
In more recent times, at least two Fortran 90/95 programs have been
written to convert from fixed to free source form, and one to convert
from C to Fortran 90
I would use Python rather than Fortran for any of these projects, but
they certainly can be done in Fortran.
beli...@aol.com
I did mention in the comp.lang.python thread where you originally
posted your essay that I was going to post it in comp.lang.fortran. See
the message
From: beliav...@aol.com
Newsgroups: comp.lang.python
Subject: Re: Python advocacy in scientific computation
Date: 15 Feb 2006 12:35:46 -0800
Organization: http://groups.google.com
I did not want to start another debate in comp.lang.python about the
relative merits of Python and Fortran.
Pierre Asselin
> [ lots of stuff snipped ]
> No, of course we still need to think. Python just makes it an order of
> magnitude easier to write the test harness and use it. Which means in
> practice that one is more likely to actually get around to doing it,
> rather than just talking about it.
Could you elaborate on that ? In my experience, writing the tests
themselves is a lot more time-consuming than wrapping them up.
Let me explain. On all my platforms there is an overhead to set
up a build structure: Makefiles on posixoids and workspace/project
files on Windows (&@#^! wizard, but I digress). Since the overhead
is already there, it is a simple matter to add a 'check' target
to the Makefile or a 'check' project to the workspace (okay, that's
harder) and automate the running of the tests. The tests themselves
are written in the target language and they are hard to *invent*.
What exactly does a scripting language bring to the table ?
--
pa at panix dot com
Bil Kleb
program ii
integer i
do i=0,10
print*,i
if (i.gt.5) goto 1
enddo
1 print*,i*i
end
Ruby (from Bil Kleb):
for i in 0..10
puts i
break if (i>5)
end
puts i*i
If you wanted "print" instead of "puts",
you'd have to add a newline character or
add "alias print puts" at the top.
Python (from Brian Elmegaard):
for i in range(10):
#begin
print i
if i>5: break
#end
print i*i
Regards,
--
Bil
http://fun3d.larc.nasa.gov
Pierre Asselin
> I'm thinking more along the lines of pasting C, C++, Fortran together
> with C, and leaving scripting languages for utility stuff like shuffling
> data files.
I have evidence to the contrary. One of our more successful internal
codes has a crude scripting feature. The script files are very
simple,
# comments
keyword arg arg ...
that sort of thing. Each recognized keyword typically causes a
subroutine to be called. The subroutines that do the heavy lifting
have more than enough work to amortize the scripting overhead.
The interpreter loop is something you can write in F77; it helps
to have an extension for list-directed internal I/O, but it is very
simple. There are no variables and no control structures. If we
want to do some sort of loop we just hack a script generator to
expand the loop into a long list of immediate commands.
Having even such a crude scripting capability makes the code
at least an order of magnitude more flexible. Users have
put it to uses that were not anticipated when we designed it.
Sometimes we hack the Fortran to add a new scripting primitive
but that's about it. Development time is much shorter and
users can participate better.
So now I'm shopping for a real scripting language, with variables
and loops, that I can embed in (or extend with) the core model.
Harold Stevens
[Snip...]
> Having even such a crude scripting capability makes the code
> at least an order of magnitude more flexible.
FWIW...
My experience with traditional *nix script "wrappers" (csh, bash, etc.)
and utilities (awk, sed, etc.) was similar. We embedded optimized codes
(almost invariably Fortran) to do the heavy floating point, and let the
scripts direct the looping, parameter adjustments, etc.
I haven't gotten much into Python or Ruby in this regard, but what very
little I know about them would appear to be more sophisticated than the
facilities traditional *nix scriptings and utilities offered.
> So now I'm shopping for a real scripting language, with variables
> and loops, that I can embed in (or extend with) the core model.
I too am fascinated by this opportunity to augment dusty deck and other
proven Fortran-based numerical models with scripting like this.
--
Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
Pardon any bogus email addresses (wookie) in place for spambots.
Really, it's (wyrd) at airmail, dotted with net. DO NOT SPAM IT.
Kids jumping ship? Looking to hire an old-school type? Email me.
Cameron Laird
Pierre Asselin <p...@see.signature.invalid> wrote:
.
.
.
>I have evidence to the contrary. One of our more successful internal
>codes has a crude scripting feature. The script files are very
>simple,
> # comments
> keyword arg arg ...
>
>that sort of thing. Each recognized keyword typically causes a
>subroutine to be called. The subroutines that do the heavy lifting
>have more than enough work to amortize the scripting overhead.
>The interpreter loop is something you can write in F77; it helps
>to have an extension for list-directed internal I/O, but it is very
>simple. There are no variables and no control structures. If we
>want to do some sort of loop we just hack a script generator to
>expand the loop into a long list of immediate commands.
>
>Having even such a crude scripting capability makes the code
>at least an order of magnitude more flexible. Users have
>put it to uses that were not anticipated when we designed it.
>Sometimes we hack the Fortran to add a new scripting primitive
>but that's about it. Development time is much shorter and
>users can participate better.
>
>So now I'm shopping for a real scripting language, with variables
>and loops, that I can embed in (or extend with) the core model.
.
.
Me, too. It's breathtaking what even the smallest amount
of interactivity returns in productivity.
The three languages that I think are clearly above all the
others in their suitability as extension languages are Lua,
Tcl, and Python, in likely order of increasing difficulty
of integration.
Bil Kleb
>
> The three languages that I think are clearly above all the
> others in their suitability as extension languages are Lua,
> Tcl, and Python, in likely order of increasing difficulty
> of integration.
For Fortran specifically, or more generally to include
C, C++, etc.?
Cameron Laird
Bil Kleb <Bil....@NASA.gov> wrote:
>Cameron Laird wrote:
>>
>> The three languages that I think are clearly above all the
>> others in their suitability as extension languages are Lua,
>> Tcl, and Python, in likely order of increasing difficulty
>> of integration.
>
>For Fortran specifically, or more generally to include
>C, C++, etc.?
.
.
Very nearly the same for all.
Brooks Moses
> Cameron Laird wrote:
>>The three languages that I think are clearly above all the
>>others in their suitability as extension languages are Lua,
>>Tcl, and Python, in likely order of increasing difficulty
>>of integration.
>
> For Fortran specifically, or more generally to include
> C, C++, etc.?
In general, I think -- Lua is specifically designed to be very easy and
lightweight to implement, with the intent that this makes it suitable
for uses such as Pierre's where the scripting language is a part of the
primary program (and can potentially act directly on its data), rather
than being a standalone interpreter that treats the primary program as a
set of library functions.
I've heard very good things about it from some people who are working on
implementing it as an extension to TeX, but haven't played with it myself.
- Brooks
--
The "bmoses-nospam" address is valid; no unmunging needed.
Brian Elmegaard
I guess I didn't have much of an argument...
The ruby course I downloaded didn't "look" that simple at first
glance.
Arjen Markus
my head for the Fortran community - there is a whole bunch of questions
that are all related and that are in desperate need for a good solid
answer.
Bil Kleb has posted a reference to a rather interesting document
explaining the issues. Yes, it is a huge task that we who are involved
in some way or another in developing scientific software are constantly
aware of (or at least I hope all of us are!).
The only excuses for not investigating these issues further are the
classical ones: no time, no resources, as it is a huge task!
I have done some bits and pieces in the area but I would love to be
able to help create a more comprehensive and authorative answer!
Regards,
Arjen (sorry for the somewhat extatic tone ...)
Arjen Markus
referred to ;).
Anyway, I am trying to find the time to add something substantial to
the discussion.
Regards.
Arjen
Bil Kleb
>
> The ruby course I downloaded didn't "look" that simple at first
> glance.
See also the intriguing 15-minute online tutorial at
Bil Kleb
>
> Could you elaborate on that ? In my experience, writing the tests
> themselves is a lot more time-consuming than wrapping them up.
>
> Let me explain. On all my platforms there is an overhead to set
> up a build structure: Makefiles on posixoids and workspace/project
> files on Windows (&@#^! wizard, but I digress). Since the overhead
> is already there, it is a simple matter to add a 'check' target
> to the Makefile or a 'check' project to the workspace (okay, that's
> harder) and automate the running of the tests. The tests themselves
> are written in the target language and they are hard to *invent*.
> What exactly does a scripting language bring to the table ?
In our case, we attempted to make writing tests as simple as
possible so that they would get written.
The dynamic language is used for several things:
1) Extend Fortran with assertions like is_true, is_false,
is_equal, and is_equal_within, and with test packaging
like begin_test, end_test, setup, teardown. This allows
the user to write their tests in Fortran with only a
very small set of shortcut "macros".
2) Turn the bare minimum "core" of pseudo Fortran the user
has written into a complete, valid Fortran module by wrapping
it with the appropriate header and trailer information to
make it compilable.
3) Through a naming convention, the dynamic language then
generates all the infrastructure Fortran used to orchestrate
the test running, such as calling each test case sequentially,
preceded by setup and teardown methods, and keeping track
of failures and errors.
4) Next, the dynamic language finds all the required dependencies,
compiles everything, and runs it.
So, with the dynamic language doing all this work behind
the scenes, the user only has to write a few lines of Fortran
with some small extensions, and the rest is handled automatically.
We even have an emacs extension to f90-mode for it. This allows
for one-button automated testing: http://c2.com/cgi/wiki?OneButtonTesting
Regrettably, even with this facilitation, some members of our
development team still claim that unit testing isn't for them,
can't possibly work, too burdensome, will kill performance, etc.
I sympathize with them, because figuring out how and what to test
is /very/ difficult. It requires programming by intent, deliberate
design, and attention to cohesion, coupling, and encapsulation.
After 6 years of test-first development experience, I still find
it very difficult at times, but I wouldn't trade it for the world.
In fact, I am now actually scared to code without simultaneously
creating a unit-test safety net under me -- without tests, it's
like solo free climbing. Also, it seems that not coding test-first
allows one to easily stray from the principles of the Scientific
Method as I allude to in http://hdl.handle.net/2002/16096
Regards,
--
Bil Kleb
http://fun3d.larc.nasa.gov
P.S. For those following along, I have obtained the first two
levels of approval (there are five total) for releasing our fUnit
Fortran unit-testing software via NASA's open source license.
Meanwhile, any "U.S. Person" can get a copy of it as part of
our FUN3D software: http://fun3d.larc.nasa.gov/chapter-1.html#s5
Arjen Markus
I also wrote a framework, a few years ago, in my case in Tcl.
This Tcl application would take appropriate definitions of variables to
be passed
to the program unit under test, fragments of Fortran source code to
actually call
the subroutines/functions, etc. and generate a complete program out of
that
which would run all the test cases and check (according to the
instructions given)
whether variables had changed (if they should change), whether
variables had
remained the same (if they should remain the same) and so on.
I have actually used it for some time and I extended it to support C as
well.
However, this approach was not as practical as I had expected:
Too much work to figure out reasonable test cases and what the answers
should be.
The problem I think is that it is easy to think of test cases for small
units,
but any larger program will have many of them, whereas you would rather
like to test larger components, but creating reasonable test cases for
those
larger components is much much more work.
One practical solution we now have installed (again based on Tcl) is a
test bench that automates the regression testing for several large
software packages we maintain and develop.
(I wrote papers on both subjects - if you are interested, just let me
know.
They are available on line - or they certainly used to be - but it is a
bit bothersoem to dig up the correct URLs ...)
Regards,
Arjen
Bil Kleb
>
> However, this approach was not as practical as I had expected:
> Too much work to figure out reasonable test cases and what the answers
> should be.
So how do you know when you're done and what you've got?
> One practical solution we now have installed (again based on Tcl) is a
> test bench that automates the regression testing for several large
> software packages we maintain and develop.
>
> (I wrote papers on both subjects - if you are interested, just let me
> know.
By all means, please bother.
Thanks,
mto...@gmail.com
> themselves is a lot more time-consuming than wrapping them up.
I'm not sure we mean the same thing by "wrapping", first of all.
It is almost always easier to use a language well-designed for the
performance of the programmer than to use a language well-designed for
the performance of the machine. That's a tautology. That these are not
necessarily the same language is the scripting advocate's claim, and it
doesn't seem all that extravagant to me.
By "wrapping" I mean the invocation of the tested code within the test
harness. In a single language situation you have the advantage, since
that step essentially is nonexistent. If the script language is
sufficiently adept at interfacing with the target language either by
virtue of
a) the target language not being F90/95
or
b) the script language performing some code generation to produce the
F9* runtime (apparently the method Bil is using)
then the extra work is essentially a one-time task amortized over all
my tests.
That's the straightforward way of answering the question, and it seems
clear to me, but I admit I'm not sure what makefiles have to do with
it.
If your idea of the scripting layer is that it competes with make, then
you don't really get it yet. (I actually think 'make' is one of the
worst customs ever to emerge in the unix community. It makes easy
things hard and hard things impossible.) But the fact that you can (and
in my opinion should) replace makefiles with scripts is secondary. The
main point is that you can (and in my opinion should) replace your
tests with scripts.
That's my straightforward answer.
My provocative answer is this.
Fortran treats the physics as the topic of interest. Shell scripts
treat the code as the topic of interest. Contemporary dynamic languages
(Python and that other one whose name escapes me at the moment being
the primary examples) treat both the code and the modeled system
equally as first class objects. This is why they are the natural medium
for expressing tests.
Consider what it would take to get a fortran module to iterate over all
the two dimesional arrays in its symbol table.
mt
mto...@gmail.com
mt
Pierre Asselin
> In article <du71t3$8tu$1...@reader2.panix.com>,
> Pierre Asselin <p...@see.signature.invalid> wrote:
> .
> .
> .
> >I have evidence to the contrary. One of our more successful internal
> >codes has a crude scripting feature. The script files are very
> >Having even such a crude scripting capability makes the code
> >at least an order of magnitude more flexible.
> Me, too. It's breathtaking what even the smallest amount
> of interactivity returns in productivity.
Oh, it's not interactive, in fact it's rather a PITA to use.
However, it is flexible. Hacking script generators is a lot
quicker than adding features to the original Fortran.