home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / apl / 1397 < prev    next >
Encoding:
Text File  |  1993-01-28  |  3.8 KB  |  80 lines
  1. Newsgroups: comp.lang.apl
  2. Path: sparky!uunet!ukma!darwin.sura.net!spool.mu.edu!torn!nott!uotcsi2!news
  3. From: cbbrowne@csi.uottawa.ca (Christopher Browne)
  4. Subject: Re: J is NOT APL (was Re: Interpreter advice sought.)
  5. Message-ID: <1993Jan28.194511.20795@csi.uottawa.ca>
  6. Sender: news@csi.uottawa.ca
  7. Nntp-Posting-Host: prgf
  8. Organization: Dept. of Computer Science, University of Ottawa
  9. References: <1993Jan25.144021.22129@csi.uottawa.ca> <C1K1GK.39q@quadsys.com>
  10. Date: Thu, 28 Jan 93 19:45:11 GMT
  11. Lines: 67
  12.  
  13. In article <C1K1GK.39q@quadsys.com> roland@quadsys.com (Roland Besserer) writes:
  14. >cbbrowne@csi.uottawa.ca (Christopher Browne) writes:
  15. >: It appears that you're implying that it is relatively unimportant
  16. >: whether or not source code can be made portable.  Much of the REST of
  17. >: the world thinks that portability is HIGHLY important.
  18. >: 
  19. >
  20. >The ability to upload/view program sources with a standard text edit
  21. >is unrelated to the issue of portability. Portability simply means the
  22. >existance of a functional and syntactic standard available and adhered
  23. >to on diverse hardware/software environments. If current communications
  24. >software imposses restrictions on the transmission and viewing of program
  25. >sources utilizing anything more than 7-bit ASCII, there is always the
  26. >simply solution to use an encoding scheme, transfer the code in question
  27. >and decode it. Yes, this apporach is inconvenient, but it should bot
  28. >be a constraint in the design of a language. 
  29.  
  30. a) The use of "standardized tools" to work with programs IS a
  31. portability issue.  The same argument has been going on on
  32. Comp.lang.forth, where people have been arguing very similar things.
  33.  
  34. b) There's ALWAYS constraints on the design of a language.  Otherwise,
  35. nobody actually gets around to nailing features down.
  36.  
  37. c) The problem is not merely in communications, it's also in editing
  38. and printing.  This has definitely been a problem with APL in the
  39. past.  As windowed GUI systems with customizable font systems grow in
  40. popularity, it MAY become less of a problem, but that's not obvious.
  41.  
  42. >: On the other hand, J allows one to apply power similar to that of APL
  43. >: in virtually any environment, whether it has "funny characters" or
  44. >: not.  Moreover, it allows you to make applications portable.
  45. >: 
  46. >
  47. >Portability is never really a problem with an infant language. Should
  48. >J proliferate it will face the same portability problems as any other
  49. >language.
  50.  
  51. It's good not to shackle it to hardware-related portability problems
  52. at stage 1.  In addition, if it's NOT reasonably portable, it may not
  53. survive infancy.  If it didn't run on a fairly large number of
  54. different systems, I don't think it would be possible for it to
  55. "proliferate."
  56.  
  57. >: Yes, it tends to look like "line noise".  So does APL, to the
  58. >: uninitiated.
  59. >
  60. >Here I most strongly disagree with you. APLs character set and nomenclature
  61. >are easily recognizable as they are based on mathimatical symbolism 
  62. >familiar to most of us. J simply overloads ASCII punctuation characters.
  63.  
  64. I said "to the uninitiated."  Most people that see it for the first
  65. time DO think it looks strange.  The fact that APL uses a different
  66. order of operations than people are used to is also confusing.
  67. Right-to-left evaluation isn't "normal."  The fact that HP calculators
  68. and the Forth language uses RPN is similarly "odd," and throws people
  69. off, at the start.
  70.  
  71. It isn't difficult to remove the overloading from J using a suitable
  72. set of redefinitions; it's difficult NOT to at least START with an
  73. "overload" when J is trying to function under ASCII.
  74.  
  75. -- 
  76. Christopher Browne                |     PGP 2.0 key available
  77. cbbrowne@csi.uottawa.ca           |======================================
  78. University of Ottawa              | Genius may have its limitations, but
  79. Master of System Science Program  | stupidity is not thus handicapped.
  80.