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...


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.


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.


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

tel:       +1 416 203 0854
text/cell: +1 416 996 4286

For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to