From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1094ba,7a6a623afb38d7f7 X-Google-Attributes: gid1094ba,public X-Google-Thread: 103376,7a6a623afb38d7f7 X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,94f5b26bc297a928 X-Google-Attributes: gid109fba,public From: "Gary L. Scott" Subject: Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) Date: 1997/09/16 Message-ID: <341F22C2.C46CE5F4@flash.net>#1/1 X-Deja-AN: 273105865 References: <5ve7c6$f4m$1@info.uah.edu> <5vlhoj$1ul@rc1.vub.ac.be> X-Priority: 3 (Normal) Reply-To: scottg@flash.net Organization: Home Newsgroups: comp.lang.c++,comp.lang.fortran,comp.lang.ada Date: 1997-09-16T00:00:00+00:00 List-Id: The problem of developing a GUI in Fortran is one of designing an appropriate API for Fortran. This used to be done quite commonly (language-specific API bindings). I have developed "graphical user interfaces" in Fortran that were highly functional (a little slow, it was 10 years ago) and very easy to develop because the API was designed "appropriately". The problem is really one of UNIX/Windows APIs being "low-level" C-oriented APIs. It is great that Fortran is being extended in ways which allow it to be able to call other languages and APIs designed for other languages, however, I shouldn't have to. OS or compiler vendors should supply language tailored API bindings. It's more work for them, but a lot less work for me, as an application developer who just wants to produce a useful product without the hassle of inter language communication which requires me to essentially know two (or more) languages, usually one of which has an appalling syntax that makes me cringe). I vote for a reduction in complexity (the K.I.S.S. principle) in the area of OS API calls from Fortran (or PASCAL or COBOL or PL/1 or . Is anybody listening? Come on, there's only 1500 or so WIN API calls, how much work could that be...). Jeffrey Templon wrote: > pvanesch@vub.ac.be (Vanesch P.) writes: > > > I think this is an essential point. FORTRAN is well-suited to do > > calculations and hard-core scientific computation. But more > > complex structures (a GUI is program-wise a lot more complicated > > than a scientific calculation) are not dealt too well with in > > fortran I think. I've seen this in the high-energy community. > > Both elements are present there: complex software systems and > > hard-core scientific computing. Well, I've seen quite a mess > > in the FORTRAN implementation (rather ad hoc) of the complicated > > datastructures that had to be manipulated. It would have been > > much better done (and the tendency now is - finally - to switch > > to things like C++) in a language suited for the task. > > I agree that there are problems that get too complex for Fortran, at > least for Fortran-77. I'm not sure these limitations apply to > Fortran-90, given the appearance of derived types and allocatable > arrays. > Perhaps F90 is not enough, but I think C++ is not the answer for > people who aren't professional programmers. Ada looks like it might > be easier for a normal human to work with and read, but I haven't > spent > much time playing with it. > > JAT