MathGroup Archive 2008

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Re: Wolfram User Interface Research?

  • To: mathgroup at
  • Subject: [mg88021] Re: [mg87994] Re: Wolfram User Interface Research?
  • From: Murray Eisenberg <murray at>
  • Date: Tue, 22 Apr 2008 06:27:04 -0400 (EDT)
  • Organization: Mathematics & Statistics, Univ. of Mass./Amherst
  • References: <fuhfdc$ihb$> <fuhrka$s88$> <>
  • Reply-to: murray at

This comment about APL is quite wrong: nothing "compelled you" to write 
"inscrutable single line programs" (except maybe in the earliest days, 
when one was sending single lines over a telephone line to a mainframe, 
then waiting for your instruction's turn to get its slice of time and 
have the result sent back and typed at your terminal).

With APL then, and with IBM's APL2 now, you MAY, if you wish, write 
overly condensed one-liners.  And indeed some APL programmers aimed to 
write as concise a program, all in one line, as they could possibly do.

But what some folks regard as inscrutable, others read with ease.  It's 
like saying that if one doesn't understand Chinese, then a couple of 
pictograms form an "inscrutable" text, whereas somebody who does 
understand Chinese finds it wholly scrutable.

What's more, many of the combinations of symbols in APL were instantly 
recongnizable to any APL programmer as so-called "idioms".

The delight of APL was, and is, that many very complicated things can, 
in fact, be expressed quite concisely, in a way that the suggestive 
graphic symbols of APL help one understand.

In fact, one could maintain that, despite the power of its 
pattern-matching, functional programming constructs, and list-handling 
abilities, Mathematica programs can be MUCH more difficult to understand 
than corresponding APL program -- because the Mathematica programs use 
all those, often long, words, and because they force one to pay close 
attention to order of precedence and to insert nested brackets.

It's really all a matter of what one has learned, and how well, and how 
accustomed one is to the language.  As just one rather simple-minded 
example, suppose you want to form the running cumulative sum of a list 
(in APL-speak, a vector) of numbers.  In APL, this is given by

   +\ vec

(and generalizes from to other binary operations).  In Mathematica 5 and 


(also generalizable) and in Mathematica 6,


(a special function that's no longer generalizable).

The APL notation is related to the APL notation for summing a list,


(which is also generalizable); the Mathematica analog is, of course:

   Plus @@ vec

I think one would have a hard time proving that "+/vec" is more 
difficult to read, especially at a glance, than "Plus @@ vec" -- or even 
"Total[vec]".  When I see "+/vec", I immediately think, "add up the 
entries in vec".

I cannot speak knowledgeably of the current situation with APL2, but for 
many years APL programmers were incredibly productive compared with 
those programming in just about all other standard computer languages. 
It's not for no good reason that, for example, major financial analysis 
systems and reservations systems were written in APL (and some still 
are, or at least in offshoots from the APL trunk).

AES wrote:
> In article <fuhrka$s88$1 at>,
>  Will Robertson <wspr81 at> wrote:
>>  it can be tempting to chain inscrutiably long commands
>> together and create an unreadable mess --- 
> As was the case, oldtimers will recall, with IBM's APL ("A Programming 
> Language"), which allowed you -- in fact, more or less compelled you -- 
> to write incredibly powerful, but totally inscrutable single line 
> programs, leading to the now classic phrase "Write once -- read never", 
> since one day later even the original coder couldn't figure out how his 
> or her code worked.
>> together and create an unreadable mess --- but of course, if you did
>> exactly the same thing with the FullForm equivalents then the result
>> would be just as hard to read, if not more so.
> Don't agree with you on this -- but nonetheless will take your further 
> comment to heart and go off and finally learn how to use @ .

Murray Eisenberg                     murray at
Mathematics & Statistics Dept.
Lederle Graduate Research Tower      phone 413 549-1020 (H)
University of Massachusetts                413 545-2859 (W)
710 North Pleasant Street            fax   413 545-1801
Amherst, MA 01003-9305

  • Prev by Date: Re: Re: Re: Timing
  • Next by Date: Re: waveform
  • Previous by thread: Re: Wolfram User Interface Research?
  • Next by thread: Re: Wolfram User Interface Research?