On Aug 21, 10:18 am, Gary Scott
sbcglobal.net> wrote:> Fly Away wrote:
>> On Aug 20, 4:04 pm, Gary Scott
sbcglobal.net> wrote:>
>>>Fly Away wrote:
>
>>>>On Aug 20, 1:45 pm, Gary Scott
sbcglobal.net> wrote:>
>>>>>Fly Away wrote:
>
>>>>>>On Aug 20, 9:51 am, Gary Scott
sbcglobal.net> wrote:>
>>>>>>>Catherine Rees Lay wrote:
>
>
>>>>>>>>>For supercomputing maybe but the vast majority of applications
>>>>>>>>>no.
>
>>>>>>>>Exactly.
>
>>>>>>>>For the vast majority of applications I'd never use Fortran.
>
>>>>>>>>But I don't use Fortran to write the vast majority of applications. I
>>>>>>>>use Fortran to write applications where I've found that it's the best
>>>>>>>>language to use. No one language will _ever_ be the answer for every
>>>>>>>>application, or even for the vast majority, so I'm not sure quite why
>>>>>>>>you're surprised that a language which, surprise surprise, is good for
>>>>>>>>some things but not others, is still alive and kicking. Every single
>>>>>>>>language out there is in exactly the same boat.
>
>>>>>>>>And number crunching is hardly _one_ application, or limited to
>>>>>>>>supercomputers, regardless of the language being used.
>
>>>>>>>And Fortran is a very good general purpose language suitable for a wide
>>>>>>>variety of programming domains.
>
>>>>>>I disagree. Although, your definition of "general purpose language" is
>>>>>>different.
>
>>>>>I'm using it to access I/O hardware through port read/writes, data
>>>>>acquisition, low level serial bus (MIL-STD-1553) programming, and
>>>>>similar "systems programming" tasks. I find that it serves these roles
>>>>>every bit as well as C, with only a single language extension
>>>>>(integer/cray/whatever pointers) and some compiler directives. F2003
>>>>>will all but eliminate my use of those extended features (some day).
>>>>>The only reason I need them though is that the APIs are written in
>>>>>another language. They could have been written compatibly but weren't.
>>>>> So ANY time you want to program using a different language than the
>>>>>API was written for (a C API and you want to use Ada, PL/1, Smalltalk,
>>>>>Jovial, Modula, whatever), you would have those interfacing issues to
>>>>>deal with. True, some languages deal with them better than others, but
>>>>>Fortran's glacier is about to melt.
>
>>>>So pretty much, to use Fortran for "general purpose programming",
>>>>whatever that may be other than number crunching, one would either
>>>>have to use extensions or call libraries written in other languages.
>>>>So I'd rather say that you have "general purpose" compilers that allow
>>>>you to perform the above mentioned tasks rather than a general purpose
>>>>language.
>
>>>I'd say that's quite a misunderstanding.
>
>> I don't think the use of the "mis" prefix is right. This is my
>> understanding based on experience and substantiated by what you said.
>> This is how I read it.
>
> You seem to be equating ability to interoperate with any random other
> programming language as an essential component of "system programming".
> It isn't. If the OS API is written in the same language or compatible
> with, then ANY compatible language can be used for "system programming".
> And there are many examples of operating systems in which Fortran was
> used for such purposes, some with no requirement for extensions.
> Extensions were commonly provided. However, there are ample examples
> in today's most common operating system APIs that effectively constitute
> language extensions to C. Microsoft makes a good living out of inventing
> proprietary language extensions.
>
>
>
Yes but generally speaking they do improve things a lot. C# is far
easier to read and program in than C++.
Similarly
VB.Net is nearly all you need in a language. (except it
lacks Fortrans number crunching like nearly all new languages). For
example, in C# or
VB.Net why the hell would you want to put math()
around an expression when you need sine or cos! Similarly for complex
numbers, the Fortran syntax is automatic once it is defined. I realise
that by overloading ones operators this can be achieved with a lot of
trouble in C++ but it is too much trouble.
What we need is a
VB.Net(actually C# would be better becuase it can
handle unmanged code) with Fotrans numerical capability. Then you
would have a language that could do anything.
K.
