If you are not an APL user, I suggest you download a copy of Dyalog APL
from www.dyalog.com,
along with RIDE, its IDE. Both are free for personal use. This will let
you make immediate
comparisons of the utility of both APL vs. J.
J was created as an attempt to remove some of the design warts from APL,
and to make
it accessible to a larger audience (Ergo, no "special" symbols, in a
pre-Unicode era).
Like all new languages, APL had a number of design problems, such as:
- Treating singletons as scalars, sometimes, in the almost always
Bad Idea of
"user convenience". This resulted in ⍳,42producing the same
vector as ⍳42, but
it DID get that User Convenience thing, as you could write
⍳⍴vector and get a result.
J, of course, introduced #vector, to obtain the item count, but
that required a bit
more insight and experience to treat items (in the J sense) as
the basis for
language definition.
That definition of ⍳N meant that a conforming extension to higher
rank N was
not obvious.
Similarly, for scalar verbs, you could write: (1 1 1⍴2)+⍳3, and
get a vector result. Similarly,
(1 1 1⍴2)+⍳2 and (1 1 1⍴2)+⍳0, BUT (1 1 1⍴2)+⍳1 would give a
rank-3 result.
This produced code that had rank errors lurking in it, e.g.,
waiting until the app was
in the field, and somebody did a database search that produced a
single-element answer.
In particular, it is not always possible to deduce the RANK of
(x+y) statically. This makes it
hard to compile APL to highly optimized code. Hence, APEX and
other Functional
Array Language compiler projects generally forbid such forms of
"singleton extension",
as does J.
- APL supports the Bad Idea of "index origin", whereas J uses index
origin 0. The Bad Idea
is that the index origin is ⎕io, a variable that was introduced
into APL to provide that
good old User Convenience -- "We don't know which index origin [0
or 1] is 'better', so
we'll give you both of them." What ⎕io DOES do is to make program
analysis, by computer
or human, harder, because you can no longer look at an arbitrary
piece of code and
tell what it does, UNLESS you can determine the value of ⎕io at any
point in that piece
(assuming that said piece uses ⍳, indexing, etc.). ⎕io also slows
down execution in any
interpreted environment that I have encountered. Finally, the only
way to write portable
(i.e., Stdlib modules) code in APL is to use "defensive
programming" - write your code so
that it will work with either value of ⎕io. Typically, this is done
by e.g., writing it using ⎕io=0,
then subtracting the incoming (to the piece of code) value of ⎕io
from ALL indices coming
in, and adding ⎕io to all indices going out.
- The infamous "axis brackets" of APL are a Bad Idea on steroids.
They introduce MORE
dependencies on ⎕io...
Axis brackets are not functional, in at least two senses:
1. The semantics of axis brackets are function-dependent - each
primitive that
uses them has its own peculiar definition of how axis
brackets are interpreted.
2. You can not write a user-defined function that uses axis
brackets.
In contrast, SHARP APL introduced the "rank conjunction", which J
later adopted.
(See, e.g., https://dl.acm.org/citation.cfm?id=55632).
The rank conjunction IS functional, applying in exactly the same
manner to all
primitive verbs, as well as to all user-defined verbs. Its
definition is straightforward and
easy to teach and use, and generation of highly efficient, optimized
code is trivial for
a compiler.
In summary, J is a simplified, more elegant version of APL that takes
advantage of
knowledge gained through the use of APL.
Character set: the character set used to describe an algorithm is
independent of
the algorithm. E.g, I can write:
i. 42 NB. J
⍳ 42 NB. APL
iota 42 NB. Dyalog APL "Dfn", where: iota←{⍳⍵}
iota(42) NB. SaC
and it is fairly clear to a reader that they all mean the same thing. I
have, in the past,
promoted the idea of "skins", to let a user select the character set to
be used for
function entry or display. Guy Steele's Fortress offered this
capability, so it is definitely
a solved problem.
Strong typing: Both languages use dynamic typing, which is to say, that
neither
has a way to force strong typing directly. There are a number of
non-portable,
inelegant ways to achieve that end, sort of, but perhaps we should ask why
you would want strong typing...
A few possible answers are:
1. I don't want complex numbers to get into my telephone number
data base.
[This happened at I.P. Sharp on more than one occasion, except
the data bases
were usually financial trading data!]
2. I want my code to run faster, and I have the idea that strong
typing will facilitate
this, by eliminating run-time type checking.
I do not know of any interpreter where this is supported, or
where it would make
any difference in performance, except maybe for some JIT
compilers, such as in
Dyalog APL.
All APL compilers that I know of, including APEX, generate
strongly typed code,
by doing whole-program analysis to deduce the type and rank of
all arrays in
the program. Hence, they are able to produce highly optimized
code that
will usually outperform all but the best hand-coded C (and are
parallel, to boot!).
3. I want to find, statically if possible, where run-time could
crop up, say due to
doing things like: "vector + 'abcd' ". This sort of "lint"
facility does not, to my
knowledge, exist for APL or J, but if you run your APL
application through any
contemporary APL compiler, it will report on any such problems
in the
course of compilation, even if you have no intention of ever
running the compiled code.
Object Orientation: I believe that Dyalog APL supports this sort of
thing, as does J. File
under Dysfunctional Programming.
Niche languages: I would put domain-specific languages, such as you
might write to perform
computational chemistry, in this class. Do you consider MATLAB,
Mathematica, Maple... to
be niche languages? [I am not sure which beholder's eye is in use here.]
A term that may be less pejorative is "Boutique Language". A boutique
tends to cater
to a small, self-selected clientele, who are willing to pay a premium
for a particular product or
service. In the same way, users of Functional Array Languages (Hey, go
to the PLDI
ARRAY2018 Workshop next month in Philadelphia!) have, in the past, used
APL and J for
reasons such as:
- extremely rapid design, debug, deployment of applications
- no need (less need) for Computer Scientists - domain
specialists can quickly
learn enough APL/J to do their research/development without
needing an IT department
- higher run-time performance than other languages, due to the
array nature of APL/J:
E.g., I.P. Sharp Associates, in the 1980's, had the world's
biggest commercially available numeric
data bases for finance and aviation. One of the interfaces
to these was a
column-oriented database engine called Retrieve. A request
such as: "How
many shares of IBM traded on NYSE over each day of the past
week?" would be
answered in less than a second.
Reuters bought IPSA and spent a fair bit of time destroying
the company, but that's another
story. Many moons later, they succeeded in replacing
Retrieve (for one application only)
by what I think was an Oracle-based system. Overnight, they
managed to perform
the same search operation in about ten minutes. This didn't
seem to bother Reuters management,
which I found odd.
- a number of Large Financial Institutions, such as merchant
banks and insurance companies,
use/used APL dialects internally for Things They Will Not
Talk About. A few that come to
mind are Morgan-Stanley, Deutsche Bank, Bank of Montreal...
Bob
On 2018-05-16 11:27 PM, jane dalley wrote:
This is my first post; my hope is this is an appropriate question.
My knowledge of APL and J is very limited so my expectation is a simple answer
that is within my limited ability to grasp.
Examples:
How similar are both APL and J?
To the best of my recollection APL could be written with EBCDIC so why J?
Can APL do everything J can do and visa versa?
Can APL and J be forced to be strongly typed?
Are APL and J capable of being Object Oriented like C++ or C#?
Would one view J as a superset of APL?
Are J and APL more than niche languages?
Sorry if any of these questions are perceived to be offensive, probably they
have been asked many times before.
Sorry also if these questions are deemed silly such as a toddler might ask.
Regards,
Jane the novice of J
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
--
Robert Bernecky
Snake Island Research Inc
18 Fifth Street
Ward's Island
Toronto, Ontario M5J 2B9
[email protected]
tel: +1 416 203 0854
text/cell: +1 416 996 4286
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
