home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / fortran / 3049 < prev    next >
Encoding:
Text File  |  1992-08-15  |  3.6 KB  |  61 lines
  1. Newsgroups: comp.lang.fortran
  2. Path: sparky!uunet!wupost!darwin.sura.net!Sirius.dfn.de!tubsibr!rzphy2.rz.tu-bs.de!i2041101
  3. From: i2041101@rzphy2.rz.tu-bs.de (Paulini)
  4. Subject: Re: C versus FORTRAN debate (WAS: Re: Welcome to HPFF
  5. Message-ID: <1992Aug15.172219.2138@ibr.cs.tu-bs.de>
  6. Keywords: HPFF, High Performance Fortran
  7. Sender: postnntp@ibr.cs.tu-bs.de (nntp inews entry)
  8. Organization: TU Braunschweig, Informatik, Bueltenweg, Germany
  9. References: <Bsy43C.9BG@rice.edu> <1992Aug14.092952.11572@ibr.cs.tu-bs.de> <1992Aug14.224112.19348@sol.UVic.CA>
  10. Date: Sat, 15 Aug 1992 17:22:19 GMT
  11. Lines: 48
  12.  
  13. Sorry, but it was'nt my intention to start a debate C vs. FORTRAN. That would
  14. be silly and a waste of time. "Cut it", as someone has said.
  15.  
  16. The essence of my article was: don't try to add completely new features to
  17. FORTRAN like parallel processes and so on. My proposal was to declare a language
  18. (lets call it NEW_LANG) as the successor of FORTRAN. NEW_LANG can have all the
  19. new features required together with a portable interface to FORTRAN, so that
  20. it is possible to use all existing FORTRAN code. 
  21.  
  22. What else have the creators of Fortran 90 done? In fact it is a completely
  23. new language. But they stopped half the way, because old FORTRAN code is still
  24. legal; and it is not possible to combine both a safe, secure, elegant and
  25. efficient language and the old FORTRAN style. BTW, we all know how unsafe, 
  26. insecure, inelegant and inefficient programming in FORTRAN is (i don't mean
  27. ineffiecient in the sense of slow execution). Fortran 90 - Syntax seems very 
  28. complex to me and it is probably not easy to make an efficient compiler
  29. (here i mean efficient _also_ in the sense of execution time).
  30.  
  31. IMHO the creation of a NEW_LANG seems to me the best possibility to solve
  32. the REAL problem we all have: writing numeric code. We all know that Standard
  33. FORTRAN (i don't speak of non-portrable extensions like VAX-FORTRAN) is in
  34. many ways a very poor language (for instance: remember the discussion in 
  35. comp.lang.fortran some weeks ago about a portable way to append something
  36. to an existing file - there is no way). I mentioned C and Ada only because
  37. they are very popular and dont't have most of the problems FORTRAN has -
  38. they have other. In the last years many numeric code has been written in C
  39. and it is the most popular programming language in the world. Most of the young
  40. people entering our institute are used to C and i forced some of them to use
  41. FORTRAN, although they disliked FORTRAN very much (like me), but at the 
  42. moment there is no other way to solve some of the numeric problems we have.
  43. But times change and if i look into the market i see some probability that 
  44. C will dominate over FORTRAN also in numeric applications. Don't misunderstand
  45. me: i don't think that C is the ever best possible language. I think there
  46. are better programming tools available (but don't say which, to not have
  47. another useless discussion).
  48.  
  49. Good postings should not be larger than my editing window - so i stop here.
  50. Thanks!
  51.  
  52. -- 
  53. #-----------------------------------------------------------------------------#
  54. # Joachim Paulini                                                             #
  55. #                                            Tel    (0531) 391-5190           #
  56. # TU Braunschweig                            Fax    (0531) 391-5833           #
  57. # Institut f. Theoretische Physik            e-mail i2041101@ws.rz.tu-bs.de   #
  58. # Mendelssohnstrasse 3                              i2041101@dbstu1.bitnet    #
  59. # 3300 Braunschweig / Germany                                                 #
  60. #-----------------------------------------------------------------------------#
  61.