home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / edu / 1510 < prev    next >
Encoding:
Internet Message Format  |  1992-09-03  |  3.0 KB
  1. Xref: sparky comp.edu:1510 comp.lang.fortran:3405 comp.lang.misc:2916 comp.arch:9202 sci.math:10928
  2. Path: sparky!uunet!decwrl!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
  3. From: hrubin@pop.stat.purdue.edu (Herman Rubin)
  4. Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
  5. Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
  6. Message-ID: <Bu08uF.HBC@mentor.cc.purdue.edu>
  7. Date: 3 Sep 92 13:44:38 GMT
  8. References: <1992Sep3.020355.20338@u.washington.edu> <2!ln9fc@lynx.unm.edu> <1992Sep3.112944.20996@dbsun.uucp>
  9. Sender: news@mentor.cc.purdue.edu (USENET News)
  10. Distribution: na
  11. Organization: Purdue University Statistics Department
  12. Lines: 42
  13.  
  14. In article <1992Sep3.112944.20996@dbsun.uucp> meyer@dbsun.uucp (Don Meyer) writes:
  15. >In article <2!ln9fc@lynx.unm.edu> john@aquarius.unm.edu (John Prentice) writes:
  16. > [ re: C++ and complex numbers ]
  17. >>Fortunately, you wouldn't need to because the designers were not brain
  18. >>dead enough to leave in out in the first place :-) .
  19.  
  20. >'C' was intended as more of a systems language, in which case complex
  21. >numbers aren't usually needed.  C++ extends C without any particular
  22. >bias towards features for specific applications areas.  The philisophy
  23. >of extending the language via librarys (which can function quite as
  24. >nicely as built-in features) is a sound one.
  25. >I would hardly characterize this _considered choice_ as "brain-dead".
  26.  
  27. This is not brain-dead, but it is certainly brain-damaged.  Inlining of
  28. stuff from libraries has to be done at compile time, or at most at assemble
  29. time, as at least the compiler needs to know how much space the inlined
  30. code will take.  If every addition, etc., required a subroutine call,
  31. the computer would run very much slower.  So one would have to use 
  32. some type of language extension file at compile time, not libraries.
  33.  
  34. The present compilers translate such things as +, *, &, etc., into 
  35. some version of assembler.  Why not allow the user to say how other
  36. operations will be similarly translated, and add them to the list?
  37. These operations often produce temporaries; why not tell the user
  38. how this is done, and let them be added to the list?  These would
  39. not really complicate the language design or the compiler, except
  40. insofar as precedence is affected.
  41.  
  42. Now why did the C designers use the term "typedef" for what should have
  43. been called "typealias"?  I have used Fortran compilers before the creation
  44. of C which allowed a limited number of user-defined types.
  45.  
  46. This also affects hardware.  It does make a difference in the code for
  47. a good program what operations are available and how long they take.
  48. On some machines, multiplication and division have to be programmed.
  49. There is generally no single algorithm optimal on all machines, so the
  50. hardware considerations at least have to be known to the programmer.
  51. -- 
  52. Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
  53. Phone: (317)494-6054
  54. hrubin@pop.stat.purdue.edu (Internet, bitnet)  
  55. {purdue,pur-ee}!pop.stat!hrubin(UUCP)
  56.