home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / apl / 1391 < prev    next >
Encoding:
Text File  |  1993-01-28  |  3.1 KB  |  72 lines
  1. Newsgroups: comp.lang.apl
  2. Path: sparky!uunet!portal!quadsys!roland
  3. From: roland@quadsys.com (Roland Besserer)
  4. Subject: Re: J is NOT APL (was Re: Interpreter advice sought.)
  5. Message-ID: <C1K1GK.39q@quadsys.com>
  6. Organization: QUAD Systems
  7. X-Newsreader: Tin 1.1 PL3
  8. References: <1993Jan25.144021.22129@csi.uottawa.ca>
  9. Date: Thu, 28 Jan 1993 08:12:20 GMT
  10. Lines: 60
  11.  
  12. cbbrowne@csi.uottawa.ca (Christopher Browne) writes:
  13. : In article <C1EIJn.I3@quadsys.com> roland@quadsys.com (Roland Besserer) writes:
  14. : >hui@fid.morgan.com (Roger Hui) writes:
  15. : >: There are some simple tests of this assertion.  For example,
  16. : >: try posting the text of an APL function to this news group, 
  17. : >: using the system editor on your machine to construct the message.
  18. : >
  19. : >This is certainly not a valid point. To hopelessly confuse the syntax
  20. : >and limit it to agonizingly obscure sequences of punctuation
  21. : >characters for the sake of being able to post verbose sources is
  22. : >nonsense. 
  23. : 
  24. : Is this an invalid point because you don't WANT it to be a valid
  25. : point, or is it invalid because the communication of source code is
  26. : unimportant?
  27. : 
  28. : It appears that you're implying that it is relatively unimportant
  29. : whether or not source code can be made portable.  Much of the REST of
  30. : the world thinks that portability is HIGHLY important.
  31. : 
  32.  
  33. The ability to upload/view program sources with a standard text edit
  34. is unrelated to the issue of portability. Portability simply means the
  35. existance of a functional and syntactic standard available and adhered
  36. to on diverse hardware/software environments. If current communications
  37. software imposses restrictions on the transmission and viewing of program
  38. sources utilizing anything more than 7-bit ASCII, there is always the
  39. simply solution to use an encoding scheme, transfer the code in question
  40. and decode it. Yes, this apporach is inconvenient, but it should bot
  41. be a constraint in the design of a language. 
  42.  
  43. : The syntax is most definitely NOT limited to "agonizingly obscure
  44. : sequences of punctuation characters" - it is quite possible (and can
  45. : be useful) to RENAME the various syntax components.  On a system that
  46. : has a sufficiently verbose character set that, say, included the APL
  47. : character set, you could assign the commands to the appropriate
  48. : character.
  49. : 
  50.  
  51. A valid point. 
  52.  
  53. : On the other hand, J allows one to apply power similar to that of APL
  54. : in virtually any environment, whether it has "funny characters" or
  55. : not.  Moreover, it allows you to make applications portable.
  56. : 
  57.  
  58. Portability is never really a problem with an infant language. Should
  59. J proliferate it will face the same portability problems as any other
  60. language.
  61.  
  62. : Yes, it tends to look like "line noise".  So does APL, to the
  63. : uninitiated.
  64.  
  65. Here I most strongly disagree with you. APLs character set and nomenclature
  66. are easily recognizable as they are based on mathimatical symbolism 
  67. familiar to most of us. J simply overloads ASCII punctuation characters.
  68. -- 
  69.  
  70. --------------------------------------------------------------------------------
  71. Roland Besserer          QUAD Systems, Santa Cruz             roland@quadsys.com
  72.