Talk:APL (programming language)/Archive 2

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Array operations vs "structured programming"

I have a problem with the semantic inference in the article vis-à-vis structured programming. The article says, for example, "... but the array operations it [APL] included could simulate structured programming constructs." In reality, it is structured program concepts, such as Do For, that are required (in other programming languages) to simulate the array operations natural to APL.

Array operations can reduce program size and complexity, often by an order of magnitude or more. Smaller programs – less code – usually offer fewer opportunities for coding errors.

It's not that structured programming is an absolute good in and of itself, but is, rather, a gimmick required to bring some semblance of order to more primitive programming languages lacking sophisticated array capabilities. -R. 21:46, 2005 May 23 (UTC)

I think that is going a bit far, and I am a full-time APL programemr, and a former chair of ACM/SIGAPL. It might be more accurate to say that in many cases structured programming and array operations can achieve the same result with different methods. There are some cases where other languages use structured constructs to do array processing. In particular the FOR loop was origianlly designed as a way to loop through the elements of an array in early FORTRAN, although it has been used for other purposes since. On the other hand, I have frequently seen array constructs used basically to simulate a classic structured construct in APL. For example the code:

{branch to} (<vector of line labels>)[<vector of possible values> {iota} {current value}

is a common APL idiom used to simulate a CASE structure, and used for exactly the purpsoe of a classic case structure, i.e. to transfer control to one of several code sections based on the current value of a varaible or expression, such that each possible value has a code section associated with it.

The general purpose of structured programming is to organize the flow of control. The general purpose of array operations is to organize the data and provide specialized tools to work with it without needing explicit contol flow for the low-level element-by-element processing. But many, indeed most significant, APL programs still need to manage control flow. Classic APL did this by simulating the structured constructs in most cases. Modern APL generally incorporates versions of structured programming constructs, such as ":IF/:ElseIf/:Else/:EndIf", ":Repeat/:Until", and ":For/:In/:EndFor" and the like. DES 21:25, 24 May 2005 (UTC)

While it is certainly true that lower-level languages can accomplish array operations -- with or without structured constructs -- I would not call those methods desirable, given that the problem admits of an easy array solution. Admittedly, not all problems are easily solved with array techniques. This situation usually derives from a poor, or inconvenient, data design.

I am reminded of a student in one of my classes who insisted on solving the homework problems using classic structured techniques, even though I took pains to make sure that an "APL solution" was possible. Her programs worked, but were always much more lengthy than the solutions I was after. She never "got it"; she never learned to think in the higher plane of multi-dimensioned arrays.

Since we are dragging out our credentials ;o) I was Chief Designer of an early (and little known) APL interpreter for an IBM system that was ultimately unsuccessful. Ours was the first interpreter to fully implement shared variables without any back-door hooks, and our design allowed general use of selection to the left of the assignment arrow. We were required to disable all but the "approved" indexing on the left, however.

---R. 02:59, 2005 May 29 (UTC)

I cited my credentials to indicate the level of my experience with APL, and that I am hardlt likely to needlessly trash APL, not to prove my case by "argument from authority".

In solving real-world (as oppsoed to academic) problems in APL, I often find structured constructs highly useful. I would never use them as a substitute for array operations -- handling arrays properly is afterall what APL does best -- but to handle true control-flow issues. Writing in an event-driven (i.e. windows) enviornemt, a CASE structure is invaluable, and there are various situations in which the looping constructs are highly useful. But the structure I use most often is probably the IF/ElseIf/Else constuct. Classic APL code uses this constuct frequettly, implementing it in the form of {branch} <label>{times}{iota}<condition or {branch} <condition>/<lable> or {branch} <inverted condition> <drop> <label> or another such idiom. IF/ELSE constructs are built by branching around branches, and a nested IF/Elseif construct can get quite baroque. The problem here isn't to get the code to do the needed branching on the appropriate conditions -- that works just fine. The problem is that the writing can be less clear to a future reader, particualrly a maintaining programmer. It is one thing to write code that works as it is first intended. it is quite another to write code that is modified and reworked again and again over the years, without needless waste of developer time. This can be done using classic APL, and done well -- I did it for a numbver of years before the structured constructs were available in the APL implemetation I was using -- but I find that the constructs make tis task far easier and simpler, when they are used properly. A programmer who insisted on using "classic" APL idioms where structured techniques are appropriate would not be long employed in my team. Neither would one who wrote APL like a non-array language, using loopiung constructs to handle an array one element at a time. DES 13:53, 30 May 2005 (UTC)

Character set

What does this mean?

Nevertheless, some critics attack not the use of a symbolic font, but rather the specific "purely circumstantial" choices that were made during the early implementation of APL, driven by the availability of a special kind of typewriter that would never become mainstream.

The unmentioned typewriter is the IBM Selectric (why was it unmentioned?). In fact, the whole sentence sounds a lot like innuendo. If this sentence can't be more specific, I'm going to delete it. Shoaler 12:41, 26 May 2005 (UTC)

Rental cost of APL on IBM mainframes

I used APL in a summer job, in 1980, doing budget spreadsheets for in-house IT use. I remember the company had only a few licenses. Recently, I saw a web page that cleaimed IBM's monthly license fee for APL for one user was something like $1K or $4K. Besides the paradigm issues, could this have held back acceptance of APL?

--MWS 20:15, 27 July 2005 (UTC)

As a matter of fact, in Europe at least, in the seventies there was quite an acceptance of APL. It was heavily used in what would now be called 'data mining'.

DEC even brought out a computer designed specifically to run APL programs. If I remember well it was called the 2020.

The basic papers by Codd on relational data bases, written long before RDBs became a reality, were directly inspired by the, then revolutionary, concept of handling data in arrays (tables) instead of linear files. In fact, all his illustrations were plain APL. One could say that relational data bases are the direct descendants of APL.

(What follows will probably be considered by many as POV. but I'm just writing from experience.)

In general APL was well accepted by end-users, but much less by the IT-department. Writing a decent APL program requires quite a different mind-set from writing a COBOL or C program. One concentrates on ""what"" is to be done instead of ""how"". It took MUCH less time for an end-user to become fluent in APL than for a professional programmer. Quite often professional programmers never attain any fluency in APL. (Maybe that explains also why APL has the reputation of being 'unreadable' and not C programs or UNIX-scripts, which are perfectly unreadable for non-programmers.)

Also, at a time when interactive use of computers was not widespread, the IT-department not always liked the unexpected supplementary use of central computer resources, especially by users who could not easily be controlled.

Many applications using APL could be replaced by spreadsheets on PC, standard statistical software packages, or the interactive use of relational data bases. These, the professional IT-specialist could control and live with, so support for APL was no longer needed, and APL largely disappeared.

The applications still remaining are usually of such a nature or complexity that it would be uneconomical or practically impossible to rewrite using standard IT-tools.

IBM was initially THE promoter of APL. It was also instrumental in its demise. I am certain that many PC users would love such a product, if they knew about it. (OK, that's pure POV). The steep license fee certainly doesn't help...

--87.67.3.164 16:32, 4 July 2006 (UTC)

1. Expansion requests

, in Europe at least,

RAS Syndrome?

If APL stands for A Programming Language, doesn't this mean that the article name has RAS syndrome (A Programming Language programming language)? Maybe this should be moved to APL (language)... --Ihope127 16:39, 26 August 2005 (UTC)

There was never a programming language called "A Programming Language." The language is called APL and was named in tribute to a book titled A Programming Language by Ken Iverson, describing a similar notation. The name "APL" is not an initialism. –Shoaler (talk) 16:52, 26 August 2005 (UTC)

This is, in a sense, true, but many APL users typically explain that it stands for "A Programming Language". More recently the ACM's SIGAPL has interpreted the latters to stand for "Array Programing Langauges". DES ^(talk) 02:07, 29 September 2005 (UTC)

Not according to this link: http://www.sigapl.org/whyapl.htm KymFarnik 00:17, 15 April 2006 (UTC)

Individuals who don't know the origin of the name APL might make up all sorts of things for APL to stand for, and if they seem logical might be passed down to others. Doesn't make them true. –Shoaler (talk) 09:38, 15 April 2006 (UTC)

Opening Paragraph

Iverson notation was not invented to describe machines. Iverson himself wrote (in the J Dictionary):

APL originated in an attempt to provide consistent notation for the teaching and analysis of topics related to the application of computers, and developed through its use in a variety of topics, and its implementation in computer systems.

Also, the phrase "to document the IBM 360 microcode architecture" is problematic. The opening sentence in the Falkoff, Iverson & Sussenguth paper says

This paper presents a precise formal descriptioni of a complete computer system, the IBM SYSTEM/360.

The problems are:

It is the IBM System/360

It is not a replacement for the existing documentation

I don't believe that at the time that microcode was used in the implementation

Roger Hui 15:45, 1 October 2005 (UTC)

While working on APL\360 I spoke to Adin Falkoff about the formal description of System/360. Before the announcement of the 360 there was an audit committee within IBM. It's mission was to ensure that the five initial 360 models conformed to the standard architecture. Some minor deviations in areas such as machine checks etc were approved by the committee. The Falkoff, Iverson & Sussenguth model was subject to review by the audit committee.

F, I & S was to my knowledge the first public use of Shared Variables. There was also an unpublished description of the 360 I/O channel. IMHO the channelmodel was flawed because it used a single shared variable for inbound and outbound tags. This made rperesentation of certain error conditions impossible. It would have also made description of the 370 Data in and Data out tags impossible. Roger D. Moore Rdmoore6 21:45, 28 December 2005 (UTC)

POV?

In the Calculation section, I noticed the following statements:

APL was unique in the apparent speed with which it could perform complex matrix operations. For example, a very large matrix multiplication would appear to take only a few seconds on a machine which was much less powerful than those today... A widely cited paper "The APL Machine" perpetuated the myth that APL made pervasive use of lazy evaluation... (emphasis added)

I'm not personally involved one way or the other, but this paragraph looks like it's been edited by someone with a serious anti-APL vendetta. What in the world is "apparent speed"? Either a program is fast, or it's not. And if, as the rest of the paragraph states, some interpreters did use lazy evaluation, why is it called a "myth"? The whole section seems sort of inconsistent. --David Wahler (talk) 14:07, 13 October 2005 (UTC)

I wrote the original paragraph and did use apparent because, if lazy evaluation was used, the interpreter would appear to complete calculations which, in fact, were deferred until needed. But then someone came along and trashed the idea that lazy evaluation was used. I had always believed this was true and, having worked for IBM for some 38 years, had been told this was true, but I couldn't prove it. Can someone else speak with more authority on this? –Shoaler (talk) 10:03, 16 October 2005 (UTC)

I added the citation of "The APL Machine", and called lazy evaluation of APL mythic - not because it was impossible, or even impractical, but - simply because it did not play a role in any of the commercial APL systems of the day.

I left "apparent speed" intact because the facts of this matter are not black and white. When used to sell APL, the word "speed" meant many things to many people. For example, should the time to punch and read the cards and the compiler CPU time be billed against the competition or not? Also, during the 1980s cache sizes were smaller, giving some advantage to the distributed loops of a naive APL evaluation sequence:

 - load the cache with an array;
 - load the instruction cache with a loop for the first array function;
 - crank through (array) functions until the end of line;
 - write out the cache.

This beat the pants off fully fused loops which would fetch scalar operands for many functions causing lots of cache line collisions. Unless evaluating lazily succeeds in avoiding work (which it surely /can/ in many APL programs), it could never compete on the many machines of the '80s with vector instruction sets, vector registers, page pre-fetching, and small but very fast cache. But I'm glad that Shoaler brought up lazy evaluation, because it reminded me of Phil's paper "The APL Machine", which was very influential, and needed to be cited in this article. I have no vendetta against APL - I was one of Burroughs' APLB authors. The beautiful thing about APL is that its language semantics /aren't/ tied to these questions of order of scalar evaluations. This is the enduring value in Iverson's design: a mathematically detached POV from which to describe the effect of computations without over-specifying the methods for achieving those effects. 67.184.17.36 (talk) 01:04, 8 December 2007 (UTC)Greg Jaxon

The sentence "For example, a very large matrix multiplication would appear to take only a few seconds on a machine which was much less powerful than those today..." doesn't make much sense without stating how large is "very large". As "matrix multiplication" is O(n^3), a factor of 10 in matrix size would make a difference of factor 1000 in computing required, so a few seconds quickly become a few hours.

Unicode and APL

Just note to remind myself to fix this later... The character above the I-key (looks like a drunk tilda ~) does not have a unicode character listed in the unicode table. (Also epsilon unicode is missing)

NevilleDNZ 17:02, 26 November 2005 (UTC)

The character above I is iota, a Greek letter that does indeed have an unicode representation.

Full table of functions and operators

It would be great if someone could put together a full table of all the APL functions and operators with their meaning. --Macrakis 19:45, 12 December 2005 (UTC)

Sounds like a good idea. I'll take a stab at it. –Shoaler (talk) 20:42, 12 December 2005 (UTC)

Okay, I've created APL operators. Comments, corrections, additions, etc. welcome. –Shoaler (talk) 20:23, 13 December 2005 (UTC)

I have looked at APL operators. My major complaint is that the term 'operator' is used instead of 'function'. All of the items in the table refer what tradional APlers called functions. APL\360 had a samll number of operators: reduction, inner (matrix) product, and outer (Cartesian) product. Later versions such as APL II, SHARP APL, APL PLUS etc provided a much richer collection of operators.

One dyadic function is missing: Circle AoB A selected a trignometic or hyperbolic function of B

The descriptions of iota and query ignore index origin but this is acceptable in this context.

It appears that you are using a CSS downloaded font for the APL characters. This doesn't work in IE or Opera (I have been struggling with this on my own site for months.) A note recommending the use of a CSS2 compliant browser such as FIrefox or Safari would be desirable.

I believe that Adrian Smith has a nicer looking APL font than that which you are using. I can provide you with a private copy as a demo but obviously permission should be obtained from Adrian before it is used on Wiki. Ideally Adrian would publish via Wiki Common so that many could use it.Rdmoore6 19:49, 2 January 2006 (UTC)

Thanks for the suggestions. I realize that "operator" is not strictly accurate, but "function" includes user-defined functions too. Maybe "APL Symbols" or "APL Function Symbols" would be better. I'll add the circle function and put in a message about using a CSS2-compliant browser. –Shoaler (talk) 12:18, 8 January 2006 (UTC)

I have renamed the page APL function symbols. –Shoaler (talk) 19:11, 9 January 2006 (UTC)

Why not scan in an IBM APL reference card? --Cowznofski

A variety of APL fonts (including Adrian Smith's Comic-Sans-based one) can be downloaded free of charge from the British APL Association website [[1]]. -- Quacksalber 05:48, 7 May 2007 (UTC)

Array Programming Language

APL never ever stood for Array Programming Language. It took its name from the book A Programming Language. Period. Please stop trying to revise history. Rlw (Talk) 03:06, 25 December 2005 (UTC)

Concur 100%. I first used APL in 1971 and it was and ONLY is "A Programming Language" from the KEI book! No if's but's or maybe's. FFS I had a copy of the bl**dy book. KymFarnik 07:17, 2 March 2006 (UTC)

Also refer IBM Publication- APL2 Language Summary SX26-3851-00 which also confirms A Programming Language with NO reference to any other name. KymFarnik 08:23, 2 March 2006 (UTC)

Another ref: ACM APL SIG http://www.sigapl.org/whyapl.htm (Defines: A Programming Language) KymFarnik 04:10, 3 March 2006 (UTC)

Concur. I have also been associated with APL since the early 70's and I never heard anyone use "Array Programming Language." Perhaps it was used in some latter-day marketing campaign that thought "A Programming Language" wasn't snazzy enough but that was never the name of the language. –Shoaler (talk) 16:21, 3 March 2006 (UTC)

Concur. I own Iverson's original book, the one mentioned above, "A Programming Language". He originally invented it as a mathematical notation for describing programming, and it was originally quite secondary that he made it an executable language rather than a specification language. Dougmerritt (talk) 04:50, 20 December 2008 (UTC)

My 9-year-old son calls it "Ancient Programming Language". 193.8.106.40 (talk) 12:38, 19 March 2008 (UTC)

Your 9-year-old does??? Why, do you encourage him to call you his Ancient Poppa Loser? A 9 year old won't use the word "ancient" without *some* kind of parental influence.

GUI

You can use the other line for I/O, or constructing a GUI.

Is that meant to be a joke? --Apus 13:01, 16 June 2006 (UTC)

Not sure about this GUI statement. It isn't really a well-informed crack, good or bad, about APL. Firstly, with the three (APL2, Dyalog, APL2000) Windows dialects of APL, you wouldn't really construct (build?) a GUI, rather you would throw up a form and some fields and stuff and have it. A good GUI in any of the APLs would require a rather different character of programming, probably nothing that you could stuff on one line. Second, really, I would rather use Visual Basic or one of those sorts of products for GUIs - APL, despite its computational expressive power, does not offer anything special. You would construct the GUI with a program. Long and tedious, though far better than with C. Lastly, early GUIs, if you want to call them that, for use on IBM 3270 hardware, were also something that you could not really do on one line, with shared variables and all that.

I/O? Not sure about that one either. APL I/O has always been nothing special. You type in characters or send them to the session. Read and write files. Connect to a socket.

--Cowznofski 24 Nov 2006

Shared Variables

I rewrote the IPSANET article and found it necessary to mention some APL related things which are not described in wiki: 1] Shared variables were the basis of IPSA NSVP. APL SV introduced shared variables in 1973. SHARP APL added them later. Perhaps a brief article on shared variables would be desirable. 2] SHARP APL is an instance of an APL interpreter. There were many other interpreters. Adin Falkoff attempted to list the IBM interpreters. A more complete list would be desirable. Rdmoore6 20:50, 1 January 2006 (UTC)

I would make a distinction in the so-called "quad-variables" between

"shared variables" as introduced by SHARP APL a.o. and which serve a single purpose like accessing files

"shared variable protocol" using quad-SVO, quad-SVC, etc (as introduced by IBM) which allows communication with an "auxiliary processor" program. This allows access from APL to anything accessible in the system and is not restricted to predefined functions. A very powerful, but rarely used, facility.

--87.67.3.164 17:15, 4 July 2006 (UTC)

Wait a minute, Sharp APL and IBM Shared Variable usage was pretty much the same. APL.SV mostly used them for TSIO. Then along came VSAPL, with APs for all sorts of stuff, GDDM, AP124, etc. APL2 brought with it AP127 (which needed nested arrays). Sharp APL had just about everything except AP100, AP101, AP102, (host commands, stack, session manager) as they were not needed. IDSH (Sharp Display Handler) was also an AP, can't remember the number (7?)

Rarely used? Not at all. Can't program GDDM without it. Or get to DB2. Shared Variables were essential. --Cowznofski 24 Nov 2006

What I meant is that very few people use the shared variable protocol to develop their own auxiliary processors although, with IBM at least, this is rather well documented. That's why I suggested the distinction between shared variables and the shared variable protocol, which exists both in APL and in Assembler or C. In fact, TSIO was originally marketed as an "example of an auxiliary processor". The first AP I heard of used APLSV as an interactive frontend to the linear programming package MPSX. Not precisely a standard application, but quite useful.

Using the protocol any program can communicate with any other program, not just with APL. However, as far as I know, it is the only standard protocol which allows APL to communicate with any other program.

Another reason I suggested the distinction is that some APL dialects use quad-variables as functions to pass data to and from the outside world without using a named AP (eg the quad with a horizontal arrow).

All the APs you mention are standard APs, delivered with the product, which in a sense proves my point. Gvandor 21:40, 12 August 2007 (UTC)

I would agree that later interfaces to APL, starting from []XP1, []NA, processor 11, and so on, were far easier than writing a shared variable processor on the mainframe. I don't remember any user-written APs, though there were several products out there like an interface to Focus. Possibly the biggest hurdle was some knowledge of assembler language, I don't recall any shared variable processors written in Fortran or PL/I.

On Unix and the PC, starting with Sharp and Dyalog APL, the barrier was lowered considerably as the shared variable processor could be done in C. Further, both Sharp and Dyalog provided good examples to start working from.

Afterwards, it kept on getting easier. STSC / Manugistics had their []XPn functions, then just about everyone had some form of []NA. Today you can connect to COM, Java, and .Net, and so on.

Cowznofski (talk) 21:13, 2 July 2008 (UTC)

POV Again

I've pulled the following out of the main article:

However, when implementing an APL module to be run using an interpreter (as was usual), a common tactic was to initially implement the module as separate, mostly understandable lines. Once the logic was verified, the lines would then be merged into one line for optimal processing in the interpreter. These APL one-liners, as they were called, were incomprehensible when viewed even a short time later. The accomplished APL programmer would document the function of the module in comments- if it had to be changed, the code would be discarded and re-implemented.

I'm not sure this is factual (who did this? when?), and if factual I don't know how relevant it is. Also the presentation ("...mostly understandable lines...") seems to not represent a neutral point of view, and could even be assuming the question. RaulMiller 06:40, 22 March 2006 (UTC) Concur KymFarnik 09:48, 22 March 2006 (UTC)

It was common for vendors of applications written in APL to remove all comments and string the lines together into a single line. This was supposed to speed up execution, but was also probably used to make it more difficult to reverse-engineer the code. –Shoaler (talk) 09:58, 22 March 2006 (UTC)

APL Users

APL has perhaps had an unusually high percentage of users who are subject-matter experts who know some APL, rather than professional programmers who know something about a subject.[citation needed]

I'm going to take this line out. The paragraph above it says more or less the same thing. Also, the above statement means different things depending on when you get out of your time machine.

• Prior to around 1986, the end of timesharing, APL was marketed to non-programmer types who needed to get some complex calculations done. This statement was mostly true.

• Around the 1990s, APL for the PCs came into the picture. This was pitched more to a consultant than an end-user, but the end-user was not ignored. This statement was maybe half true.

• With the various Windows APLs, notably Dyalog and APL2000, you need to be more of a "professional" to use APL effectively. It is still far easier for the economist to pick up APL and get some results, but it may not be practical for the same individual to attempt to write an interface to get numbers out of a database or scrape numbers from a web page. This may be not so with APLX. In any event, this statement is barely true.

Cowznofski 21:56, 24 December 2006 (UTC)

Requested move

APL programming language → APL (programming language) – Conformance with WP naming conventions atanamir

• Wikipedia talk:WikiProject Programming languages/Renaming poll

APL for .NET link broken

APL for .NET link broken

APL for .NET

Dyalog doesn't have a .net APL quite yet, though they may have one at some time.

Maybe better to have a link to APL2000's (now APLNext?) .net development

APLNext for .net

Problem is that this new language deviates substantially from what many consider to be APL.

OpenAPL

Given that a number of APL implementations are listed, it might be appropriate to list OpenAPL. It's a reasonably complete implementation and it's open source. Paul Koning 21:04, 3 July 2007 (UTC)

A common philosophy when implementing a computer language is, "When in doubt, leave it out." The exact opposite can and should be said about Wikipedia in general. "When in doubt, put it in." If you have a useful fact or tidbit or something which fits in the article, put it in. It will invariably be changed, refined, corrected, re-aligned, slanted, or otherwise changed, but most importantly, it will not be lost. Of course it's appropriate to list OpenAPL.

The whole world reads this stuff.

Cowznofski (talk) 11:19, 24 February 2008 (UTC)

A-Class

I'd like to work this article into a class A article. Reading some of the other Class A articles, I don't see it as a particularly difficult task. Mostly, I feel we need to separate aspects of APL History from the current APL situation. Things like the APL character set are a time-waster, much of the material concerns keyboard layouts no longer in use, but could belong in APL History. There are a lot of POV statements which need to be polished up or removed. The article potentially would become somewhat smaller. Cowznofski (talk) 18:01, 13 February 2008 (UTC)

I strongly disagree with your statement that including details on the APL character set is a time-waster. As an APLer from the mainframe days 30+ years ago, I remember only too vividly how overstriking and similar matters used to intrigue my colleagues. However, I do agree that it should belong under the "APL History" heading. IllseNell (talk) 09:04, 18 June 2009 (UTC)