On 8/12/2010 3:34 PM, Jim Lux wrote:
John Smith wrote:
....
FORTRAN is far from dead in applications processing massive arrays (just
about any finite element program). For instance, I'd venture that most
weather prediction codes are in FORTRAN (MM5, which is a widely used
mesoscale modeling code, is in FORTRAN, as is WRF), as are a lot of
structural analysis (e.g. NASTRAN is in FORTRAN), and virtually ALL
electromagnetics codes.
These days, I choose to program, almost exclusively, in assembly and
C/C+/C++ (all C looks the same to someone writing in it.) If someone
hands me a FORTRAN coded work, I can read it, but it tends to look like
a mess to me. I simply run it though a source translator/optimizer and
I have C code. When I am done, if they requested the result in FORTRAN,
I run it back through the translator in reverse. C is simply a
universal language which has the most favor with engineers and which has
become the industry standard. Like I said, arguing language is a moot
point ...
FORTRAN is hard to beat when it comes to specifying array operations,
and such. Running gridded models doesn't require much in the way of
pointers or string manipulation, which are admittedly a pain in older
FORTRANs (pre FORTRAN-90 or FORTRAN-77). FORTRAN also has an intrinsic
Complex type which is nice.
FORTRAN is not "hard to beat" at anything. Assembly instructions are
the only "real code" which a processor understands, it is the binary
language of processing units. There is not a computer language in
existence which does not translate to assembly before execution.
FORTRAN and C only differ in semantics. While FORTRAN was an attempt to
make the language more readable in translation, C is an attempt to make
the language more efficient in translation. The goals of the two
languages are not exact.
Compilers for numerical analysis applications (e.g. those weather grid
models) for FORTRAN are highly optimized, too. There's also nifty tools
like FLIC (FORTRAN Loop and Index Converter)
The meaning of that is just moot, and implies an argument for leaving
something unoptimized would be someones goal, somewhere, for what
purpose that would be baffles me!
There's even new versions of FORTRAN coming out.
As I admitted, there are almost religious devotions to some languages
.... another point which baffles me.
....
Unless you need compatibility and interoperability. Sure, there are
non-patented communications coding schemes like LDPC that give better
performance than, say, Turbo codes (patented), but if you need to build
a radio that interoperates with a radio using Turbo codes, you're pretty
well stuck.
That is some gobble-de-gook which defies meaningful translation ...
perhaps a dynamic demonstration of obfuscation? To someone outside the
field, I can see how it might just work!
All the various high performance low bit rate voice codecs have similar
issues. All the "good" ones are patented, as well as most of the "not
quite so good", and the patents are broad enough that you would have a
tough time designing around them. (which is actually, I think, how it
should be.. patents *should* be for fairly general conceptual leaps, not
for some fiddly little detail that's different.. that's what "design
patents" are about)
Fortunately, the patents *will* expire. Unlike copyright, which has an
ever longer tail.
The best ones have not even been thought-of/invented yet! However, you
remind me of that patent office employee who once mentioned "the fact"
that most patents had already been patented ... and your statement is
just as valid as his!
....
I don't think so. It's here now, especially if you consider advanced
signal processing or protocol handling in software. The software is just
the means by which the invention is realized, and it's no different than
doing it with discrete hardware components. While raw "algorithms" and
"math" can't be patented, a clever and efficient implementation
technique certainly can be.
.... more obfuscation ... but does acknowledge the basic truth that
truths cannot be patented.
Regards,
JS