Thanks, @Roger. I want to see the post you've just made referenced in the Discussion page(s). Maybe not via copy/paste, but insert a PiperMail reference.
IMO we don't use the Discussion page that MediaWiki provides nearly enough. If you examine the 2 papers deeply enough, you see there are *issues* – and controversial choices I made in the J version. Why, for instance, do I use Table (/) in the J paper, whereas Bernard uses Jot-Dot with a logical operator, thereby losing a fundamental point about Dot that Bernard seems to be making? Bernard's article is sheer Poetry, and I've been attempting translation as opposed to blind transliteration. The choices I've made are subjective ones. Others may rightly object. Bernard's paper must not be overloaded. But the Discussion page could profitably examine such issues. On Sat, May 26, 2018 at 12:08 PM, roger stokes <[email protected]> wrote: > 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
