home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / misc / 3568 < prev    next >
Encoding:
Internet Message Format  |  1992-11-10  |  3.2 KB
  1. Path: sparky!uunet!noc.near.net!hri.com!spool.mu.edu!news.cs.indiana.edu!noose.ecn.purdue.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
  2. From: hrubin@pop.stat.purdue.edu (Herman Rubin)
  3. Newsgroups: comp.lang.misc
  4. Subject: Use of hardware capabilities.  Was: Re: Pointers
  5. Message-ID: <BxI802.7EL@mentor.cc.purdue.edu>
  6. Date: 10 Nov 92 14:24:01 GMT
  7. References: <1992Nov4.093545.15950@rdg.dec.com> <Bx7oAz.7Lp@mentor.cc.purdue.edu> <1992Nov9.121317.3914@syacus.acus.oz.au>
  8. Sender: news@mentor.cc.purdue.edu (USENET News)
  9. Organization: Purdue University Statistics Department
  10. Lines: 51
  11.  
  12. In article <1992Nov9.121317.3914@syacus.acus.oz.au> ian@syacus.acus.oz.au (Ian Joyner) writes:
  13. >hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
  14.  
  15. >>Computer hardware quite properly uses pointers, and any software that
  16. >>does not is just making life difficult for the users.
  17.  
  18. >Firstly, computer hardware does not necessarily use pointers.
  19.  
  20. >Secondly, where different architectures do use pointers, the definition
  21. >of them can be quite different. As I have already said, Unisys A Series
  22. >have quite a different kind of pointer to that which C likes. In fact
  23. >the hardware defines a higher level more problem oriented kind of pointer
  24. >than C.
  25.  
  26. >Thirdly, if you want direct access to hardware capabilities, then you may
  27. >as well use assembler. The disadvantages should be well known. Such languages
  28. >are solutions or 'how' oriented, not problem and 'what' oriented. This means
  29. >that you are not implementation independent, which makes portability difficult.
  30. >This also makes maintainability difficult. This style of programming locks
  31. >you into certain ways of doing things, instead of giving you the freedom
  32. >that higher level languages give you.
  33.  
  34. It is very difficult to be completely implementation independent, but I
  35. agree it is a good idea to be partially portable and partially implementation
  36. independent.  The current HLLs clearly do not have enough in them to do this;
  37. a very simple example is the process of packing or unpacking floats, which
  38. is mainly portable in use, but not in design.  The infamous 4.2 BSD frexp(),
  39. which used portable code to do something weaker, and often took a long time
  40. to do something simple (it could have even gone on forever), is an example.
  41.  
  42. In addition, assemblers have atrocious syntax.  At least provide the 
  43. programmer with a good macro processor (a totally non-optimizing mini
  44. compiler, which can use types, storage locations, etc.) to get around 
  45. this.  Even in assemblers which appear to have the same syntax, they
  46. do not; the order of the arguments is not constant for a given instruction.
  47.  
  48. Portability of certain ends does not mean portability of the means.
  49.  
  50. >Customers are becoming more sophisticated, and do not like to be locked
  51. >into closed systems (proprietary systems are not necessarily closed), or
  52. >into Unix for that matter. 
  53.  
  54. But is not locking into a HLL being locked into a closed system?  
  55.  
  56. Which languages allow the introduction of new operators?  Syntax is
  57. important for both producing code and understanding it.
  58. -- 
  59. Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
  60. Phone: (317)494-6054
  61. hrubin@snap.stat.purdue.edu (Internet, bitnet)  
  62. {purdue,pur-ee}!snap.stat!hrubin(UUCP)
  63.