Newsgroups: comp.lang.apl
Path: watmath!watserv2.uwaterloo.ca!mach1!torn!nott!uotcsi2!news
From: cbbrowne@csi.uottawa.ca (Christopher Browne)
Subject: Re: J is NOT APL (was Re: Interpreter advice sought.)
Message-ID: <1993Jan28.194511.20795@csi.uottawa.ca>
Sender: news@csi.uottawa.ca
Nntp-Posting-Host: prgf
Organization: Dept. of Computer Science, University of Ottawa
References: <1993Jan25.144021.22129@csi.uottawa.ca> <C1K1GK.39q@quadsys.com>
Date: Thu, 28 Jan 93 19:45:11 GMT

In article <C1K1GK.39q@quadsys.com> roland@quadsys.com (Roland Besserer) writes:
>cbbrowne@csi.uottawa.ca (Christopher Browne) writes:
>: It appears that you're implying that it is relatively unimportant
>: whether or not source code can be made portable.  Much of the REST of
>: the world thinks that portability is HIGHLY important.
>: 
>
>The ability to upload/view program sources with a standard text edit
>is unrelated to the issue of portability. Portability simply means the
>existance of a functional and syntactic standard available and adhered
>to on diverse hardware/software environments. If current communications
>software imposses restrictions on the transmission and viewing of program
>sources utilizing anything more than 7-bit ASCII, there is always the
>simply solution to use an encoding scheme, transfer the code in question
>and decode it. Yes, this apporach is inconvenient, but it should bot
>be a constraint in the design of a language. 

a) The use of "standardized tools" to work with programs IS a
portability issue.  The same argument has been going on on
Comp.lang.forth, where people have been arguing very similar things.

b) There's ALWAYS constraints on the design of a language.  Otherwise,
nobody actually gets around to nailing features down.

c) The problem is not merely in communications, it's also in editing
and printing.  This has definitely been a problem with APL in the
past.  As windowed GUI systems with customizable font systems grow in
popularity, it MAY become less of a problem, but that's not obvious.

>: On the other hand, J allows one to apply power similar to that of APL
>: in virtually any environment, whether it has "funny characters" or
>: not.  Moreover, it allows you to make applications portable.
>: 
>
>Portability is never really a problem with an infant language. Should
>J proliferate it will face the same portability problems as any other
>language.

It's good not to shackle it to hardware-related portability problems
at stage 1.  In addition, if it's NOT reasonably portable, it may not
survive infancy.  If it didn't run on a fairly large number of
different systems, I don't think it would be possible for it to
"proliferate."

>: Yes, it tends to look like "line noise".  So does APL, to the
>: uninitiated.
>
>Here I most strongly disagree with you. APLs character set and nomenclature
>are easily recognizable as they are based on mathimatical symbolism 
>familiar to most of us. J simply overloads ASCII punctuation characters.

I said "to the uninitiated."  Most people that see it for the first
time DO think it looks strange.  The fact that APL uses a different
order of operations than people are used to is also confusing.
Right-to-left evaluation isn't "normal."  The fact that HP calculators
and the Forth language uses RPN is similarly "odd," and throws people
off, at the start.

It isn't difficult to remove the overloading from J using a suitable
set of redefinitions; it's difficult NOT to at least START with an
"overload" when J is trying to function under ASCII.

-- 
Christopher Browne                |     PGP 2.0 key available
cbbrowne@csi.uottawa.ca           |======================================
University of Ottawa              | Genius may have its limitations, but
Master of System Science Program  | stupidity is not thus handicapped.
