Well done, Ian.  I thought there was a nice flow to the material, and I
guess you, Mrs Camacho and M Legrand should all take credit.

Your post prompted me to dig out a draft I wrote a while ago, addressing
the same problem (getting people intererested in J) from a different point
of view. It's quite short,  so here it is:

                                   WHY J IS INTERESTING AND DIFFERENT

Here is an outsider's view of the J language. It is offered with the aim of
 showing what makes J interesting and different, and
so to give the newcomer to J some motivation and some idea of what to
expect.

Summary:

   *  For computer programs, brief is good.

   *  J programs can be very brief.


Brief is Good
=============

Brevity can relieve the programmer of the drudgery of composing, typing and
 correcting long texts.

Brevity can make it easy to learn by experiment. Only a few keystrokes need
be entered into the computer to try out an idea.

Brevity can make it easier to see directly that a program is correct or
incorrect.

Brevity can make it easier for programmers to discuss problems and
solutions,  paricularly by emails to an online forum.

In 1998 there took place the first contest organized by the International
Conference on Functional Programming.  Teams of programmers competed
 against each other.  A special Judges Prize was awarded to the J entry,
 in part because it was said by the judges to be "astoundingly brief" .
More detail at http://www.jsoftware.com/papers/pousse.htm


J Programs Programs Can Be Brief
================================


Firstly J is array-oriented: data is regarded as naturally occurring not
just in single values but commonly as several or many values all to be
treated in the same way.  Hence an expression such as

    C =:  A + B

can mean: add each number in list A to the corresponding number in list B
to produce a new list which is given the name C.
Consequently iteration (looping) and recursion are rarely necessary;  often
the tedious machinery of program flow-control simply drops away.

Secondly, much can be conveyed in a few well-chosen words, but in that case
we must have many words to choose from. J offers a large collection of
predefined functions, in particular for the many useful ways of  dealing
with arrays.

Thirdly, J offers what is called the "tacit" style of programming,
sometimes called  "point-free" or "function-level" programming.
For an example, suppose we have two functions SQU for squaring numbers and
SUM giving the sum of the numbers in a list.
Then to define a new function which computes the sum of the squares of a
list

    SUMSQ =: SUM @: SQU

This is exactly analogous to C =: A + B . Just as + is a function which
takes two arguments (A and B) to deliver a new value (C), so @: is a
function  which takes two arguments (the functions SUM and SQU) to deliver
a new function  (SUMSQ).  @: is just one of many higher-order functions
available,   so J is like a  construction kit with many useful connectors
and adapters
 for building  new functionality.

To further aid compact expression, there is a scheme for giving meaning to
short lists of functions.  For an example, the average of a list of numbers
is the sum divided by the number-of-items.  The function divided-by is %
and the function
number-of-items is # so we may define a new function:

    AV =: SUM % #
Fourthly, J promotes brevity by naming most of its built-in functions in
only one or two characters.   For example {. (left-brace period) is the
function which gives the first item of a list.

One consequence of all this is that the newcomer to J can expect to
encounter J programs and expressions which are pretty inscrutable. For
example

   **** !

is a meaningful expression, with non-trivial structure,  defining a
function.  Hence the J programmer, more
than most, is called upon to exercise some artistic judgement over how a
program is presented.






On Sat, May 26, 2018 at 5:57 AM, robert therriault <[email protected]>
wrote:

> Nicely done Ian,
>
> For me that really is a very good introduction to the language. Now for
> the question that you often ask, "Does it do the same for those who do not
> already know the language?"
>
> For that we will have to await the response from "fresh eyes". If it has
> the same power for them then it would be an excellent introduction and
> should be promoted.
>
> Cheers, bob
>
> > On May 25, 2018, at 9:38 PM, Ian Clark <[email protected]> wrote:
> >
> > Way back in 2008 Chris Burke drew attention to an article in Vector 23/1
> by
> > Bernard Legrand, translated by Sylvia Camacho, entitled *APL – a Glimpse
> of
> > Heaven.*
> > This was first presented at a conference of 22 June 2006, organized by
> > AFAPL: *Association Francophone pour la promotion du langage APL.*
> > It was an unashamedly evangelistic appeal to the "diplodocus generation"
> of
> > C/C++ programmers to take APL seriously as a professional language.
> > In: http://code.jsoftware.com/wiki/Articles/APL_-_a_Glimpse_of_Heaven
> > Chris conjectured that the article would need only minor changes to
> offer J
> > in place of APL. He offered it as an "interesting exercise for the
> > beginner".
> >
> > However the challenge was never taken up… until now.
> >
> > Ladies and Gentlemen, it gives me great pleasure to present to the world:
> >
> >   http://code.jsoftware.com/wiki/Articles/J_--_a_Glimpse_of_Heaven
> > by Bernard Legrand,
> > translated by Sylvia Camacho and done into J by yours-truly.
> >
> > I have to say the exercise was not quite as easy as Chris made it out to
> > be. A little beyond the reach perhaps of even the most vainglorious J
> > beginner. Nevertheless it was an exercise worth doing.
> >
> > Firstly I had to correct some of the code examples and their results:
> these
> > were occasionally garbled in the original article. The result is here:
> >
> >   http://code.jsoftware.com/wiki/Articles/APL_--_a_Glimpse_of_Heaven
> >
> > and I have to say it affords a better baseline than the Vector original
> for
> > comparing the two versions of Bernard Legrand's brilliant paper. Not only
> > because the code examples and their results now tally between the J and
> APL
> > papers, but also because they can profitably be read side-by-side in a
> > strictly compatible format.
> >
> > In a recent posting: *[Jchat] How close is J to APL?*
> > Jane Dalley asked seven provoking questions, which included these:
> >
> > 1. How similar are both APL and J?
> > 3. Can APL do everything J can do and visa versa?
> > 6. Would one view J as a superset of APL?
> > 7. Are J and APL more than niche languages?
> >
> > I submit that Bernard Legrand's matching pair of papers offers the J
> novice
> > the best answers I've ever seen to these FAQs. Even if you know both
> > languages well, it is most instructive to see them compared in this
> manner.
> > And if you know neither language well, you may still find yourself
> > contemplating milestones in the emergence of Array Programming Languages
> > you never imagined you'd profit from knowing much about.
> >
> > The power of Bernard's treatment rests more in what it doesn't say than
> in
> > what it does. He seems barely to scratch the surface of APL, let alone J
> –
> > yet that enables him to highlight the genuinely remarkable facets that J
> > and APL offer to the "diplodocus generation", facets so mundane for us
> > old-hands that we overlook their crying need for careful explanation.
> >
> > Practically the only aspect that J-ers will baulk at is Bernard's
> plaintive
> > enthusiasm for APL symbols. But after nearly 60 years, is that a topic on
> > which anything is left unsaid?
> >
> > Ian Clark
> > ----------------------------------------------------------------------
> > For information about J forums see http://www.jsoftware.com/forums.htm
>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to