home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / fortran / 3241 < prev    next >
Encoding:
Internet Message Format  |  1992-08-27  |  1.7 KB
  1. Path: sparky!uunet!cs.utexas.edu!swrinde!mips!darwin.sura.net!uvaarpa!cv3.cv.nrao.edu!laphroaig!cflatter
  2. From: cflatter@nrao.edu (Chris Flatters)
  3. Newsgroups: comp.lang.fortran
  4. Subject: Re: Scientists as Programmers (was Re: Smal
  5. Message-ID: <1992Aug27.215104.2917@nrao.edu>
  6. Date: 27 Aug 92 21:51:04 GMT
  7. References: <9224105.4585@mulga.cs.mu.OZ.AU>
  8. Sender: news@nrao.edu
  9. Reply-To: cflatter@nrao.edu
  10. Organization: NRAO
  11. Lines: 28
  12.  
  13.  
  14. In article 4585@mulga.cs.mu.OZ.AU, fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
  15. >minch@lotka.stanford.edu (Eric Minch) writes:
  16. >
  17. >>... in my experience FORTRAN-writing scientists  
  18. >>can whip out working algorithms just fine. The problem comes when they  
  19. >>have to deal with data structures more complex than arrays, programs  
  20. >>longer than about a thousand lines, and mainly when turning algorithms  
  21. >>into maintainable production code. I've sometimes wished that  
  22. >>scientists were taught in a language with no I/O statements.
  23. >
  24. >Maybe you should try teaching Haskell to upcoming scientists.
  25. >Haskell is a pure functional programming language (with lazy evaluation)
  26. >that has no statements that cause side-effects. I/O is programmed by
  27. >considering the program as a function from input to output, or more
  28. >generally a program is a function from one operating system state to
  29. >another (roughly speaking).
  30. >
  31. >Personally I think that a clear separation of functions which have side-effects
  32. >from those that don't is a very good thing, but there is still a need for
  33. >those in the former class. ML is probably a better alternative as a
  34. >fuctional language if efficiency is much of a concern.
  35.  
  36. How about Sisal.  Its I/O facilities are primitive (to say the least)
  37. but it is demonstrably at least as fast as FORTRAN.
  38.  
  39.     Chris Flatters
  40.     cflatter@nrao.edu
  41.