Talk:APL (programming language)

From Wikipedia, the free encyclopedia

APL is renowned for ... being able to express an air traffic control system in two lines of code.

I suspect this may be an exaggeration. --Brion 22:08 Sep 20, 2002 (UTC)

Probably, but it's not too far from the truth, and may well be literally true for some appropriate definitions of "line" and "traffic control system". It really does capture something of the flavor of the language; I'd be inclined to call it a colorful way to express that, or a rhetorical exaggeration. I don't think figures of speech like that are entirely out of place here. --LDC

Well, the quote about shuffling and dealing a deck with four non-standard characters is most certainly an exaggeration. The program is (I think) "13 4⍴52?52". Besides, that's just for four players, and a program for Rook would be three times as long. Quamaretto 15:41, 28 February 2006 (UTC)

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

[edit] APL character set

The current table doesn't do much for me, and I know I have Unicode installed. LaTeX has most, if not all, of the characters (I'm still figuring out how to get the sort function to work in LaTeX). Meanwhile, here's an APL keyboard layout image.... I'm working on permissions.

Image:APL keyboard.gif

-- UtherSRG 15:55, 12 May 2004 (UTC)

I've commented out the table again. Perhaps some explicit instructions how how to ensure readability would be good. I know I have Unicode installed, but I can not see most of the APL symbols. - UtherSRG 14:24, 13 May 2004 (UTC)

Instructions will depend on the system you use. Some browsers (e.g. Mozilla and Lynx under Linux) show all APL characters without any additional setup whatsoever. There is no reason to hide the table, because it is not essential here. Perhaps it will prompt readers to get an APL-compatible font if they are really interested in APL. — Monedula 14:48, 13 May 2004 (UTC)

I'm really interested in APL and I can't figure out what's wrong. I have MSIE 6.0.2. I have Unicode installed. What else is required?

Leaving the table there and broken for the majority of folks is not acceptable withouth giving good instructions on how to view it. When I asked Rex Swain (owner of the keyboard image) to use his image, he visited the page and said he couldn't view the table. There aren't many folks more interested in APL than he is. - UtherSRG 15:01, 13 May 2004 (UTC)

The broken table has made you aware of a problem? It is very good!

Now the instructions. In MSIE go to menu, press Tools, then Internet Options. In the dialog box press the button Fonts.... The "Fonts" dialog box appears. In the Language script box select "Latin based". Now in the Web page font box select a font what contains the APL symbols. One of such fonts is Arial Unicode MS. This font is supplied with "Microsoft Office" — if you have istalled it, then you should have the font. If not, copy this font from someone else's machine. Or get any other font that is both APL- and Unicode-compatible and install it, and then select it in the Web page font box.

In any case, displaying characters is the browser's problem, not Wikipedia's. Wikipedia supplies information, browser displays it. Do not break up this division of labour. — Monedula 15:31, 13 May 2004 (UTC)

Outdenting...Thanks for the instructions. As things stand, I have the following fonts that should display the APL symbols: Lucinda Sans Unicode, SImPL, VectorAPL, and SILDoulosUInicodeIPA. Of these, only SImPL displays the APL characters in the table, and the font is ugly for regular text. I've now installed Arial Unicode MS and things are good.

I'm fully in agreement with the division. It's just that when the information is only viewable if the user performs a reconfiguration, then it isn't really information, only raw unintelligible data. Doubly so when there are no instructions on how to perform that reconfiguration. - UtherSRG 15:57, 13 May 2004 (UTC)

Now, to complaints about the table's contents. It seems this table is far from complete. While the table has many overlayed characters, it doesn't have all of the individual characters used in the overlays, only the special characters. I think it wouldbe beneficial to have all of them, including the "common" characters like ?, (, and ). - UtherSRG 16:04, 13 May 2004 (UTC)

If we include ? and ( ), then probably we should include A-Za-z and 0-9 also?

As to browsers: I believe that future versions will display a much wider range of characters, perhaps downloading fonts automatically when they encounter something new. — Monedula 18:10, 13 May 2004 (UTC)

May I make a suggestion? Start with the current ("Unified") keyboard, and work backwards through time. The old stuff, although interesting, is not as important as what is currently done.

The current keyboard table and the previous one (from Rex Swain, the black letters and lines on sort of a buff background) reflect the way it was in 1966. I've seen the picture hundreds of times over the last 30 years, it's a picture of an IBM Selectric, known today as the "Classic" APL keyboard. Since then, the following has happened:

APL/ASCII printer terminals came into the picture (a few new characters) - mostly Diablo-style daisywheel printers
Dot matrix printers and video display terminals, Decwriter, Datamedia, HDS, others
IBM 3270 family with its alt keyboard
IBM PC comes out, STSC APL/PLUS*PC shortly afterwards. The latter includes a character generator chip
Special (Non-IBM) APL terminals etc. rapidly become extinct
Paul Berry (or someone like that) at IPSharp develops the "Union" keyboard. The big idea is to leave the usual ASCII characters in the usual ASCII places, and make the APL symbols available with alt key sequences. Suddenly we see APL code with lower case letters. This would have been in the early 1980s.
STSC comes out with their PC product and this has the "Unified" keyboard. Not sure what the real differences between "Union" and "Unified" are.
STSC also drops (and a good thing too) the idea of undescored letters, and uses upper and lower case instead.
Slowly the world switches over to some kind of Unified keyboard. I was a late bloomer - didn't make the switch from Classic Keyboard to Unified until 1998 or so.

Cowznofski 16:24, 10 February 2007 (UTC)

What do you think of the language J as an APL renewal? Marc Venot 02:24, 3 Aug 2004 (UTC)

J is very, very impressive. If you haven't tried it, give yourself a chance and download it: it is free. IMO, it is more powerful and much more orthogonal than any other APL I've seen. The only unsatisfied wishes I can think of when I use it are:
1. I miss the user data type features provided by Backus FL (several of the more powerful J ideas come from FP via FL)
2. ditto for the exception handling mechanism in FL
3. direct, primitive support for dictionaries (K's handling of its namespaces through standard dictionaries would be very nice to have) and trees.
4. pattern-based case parsing at function definition time (à la Miranda or Haskell)
5. full, Perl-level, primitive support for regular expressions (currently it is handled through a library)
6. the fact that not all primitives work transparently on both dense and sparse arrays (although many do)
7. the fact that its Linux version runs on a Java-built interface, instead of, say, Qt
8. K's mature support for data warehouses and other OLAP-related tasks
9. last, but never least... a different way of encoding the dictionary verbs (J uses the idea of extended base characters for related functions, so that if + means something, then +. means something related and +: means something else related too... the problem is that all my years of reading have though my brain to see the '.' and ':' chars as separators and it is very hard to learn to see them attached to another character in an undivisible pair... furthermore, there is no lexical distinction between the monadyc and dyadic uses of a verb, making it even more difficult to parse what already are very dense (in the information-load sense) expressions)
In the end, though, J is the most powerful language I have ever used, and I would not consider anything else (except some kind of J descendant) to use as my main programming tool, at any price. When I work with J, I see things differently, in a fun, always entertaining way. Hope this helps a bit. — danakil 02:44, Sep 6, 2004 (UTC)

[edit] quote by dijsktra

"APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums". (Edsger Dijkstra)"

I have removed the quote by dijkstra on the following grounds:

The criticism was made towards the early versions of APL, particularly targeting its lack of support for structured and modular programming, at a moment where these two disciplines were taking over the world by storm.
Computer science was an explodind, intensely competitive field at that time, and thus it was then much more common for computer science luminaries to express themselves in ways that might have been customary then, but that today would be less acceptable for a serious researcher.
Finally, I will cite another quote by Dijkstra, criticizing another (now well respected) programming language for which I will initially remove the name calling it 'X' (note, please, that I have the greatest respect of Dijkstra's capabilities, and this is just to show that it is easy to obtain a quote supporting almost any topic from any great mind's past):
- "X had its serious shortcomings: what became known as "shallow binding" (and created a hacker's paradise) was an ordinary design mistake; also its promotion of the idea that a programming language should be able to formulate its own interpreter (which then could be used as the language's definition) has caused a lot of confusion because the incestuous idea of self-definition was fundamentally flawed. [...] My first introduction was via a paper that defined the semantics of X in terms of X, I did not see how that could make sense, I rejected the paper and X with it. My second effort was a study of the X Manual from [Academic Institution] which I could not read because it was an incomplete language definition supplemented by an equally incomplete description of a possible implementation; that manual was poorly written that I coud not take its authors seriously, and rejected the manual and X with it." (Dijkstra, Computer Science: Achievements and Challenges)
Guessed which the language is? Right. Lisp. This should throw some light into the issue of how much weight can be given to his previous quote regarding APL. Dijkstra was a genius at computer science, but Iverson's and McCarthy's genius lay somewhere else, in the specific field of languages and systems that help people think. — danakil 02:25, Sep 6, 2004 (UTC)

[edit] quote by David Given

Is the "shuffling cards in four characters" quote true, or is it just a joke? If the former, the four characters should be given in the article; if the latter, maybe a comment to that effect would be nice.

The expression 52 ? 52 will give you a pesudo-random permutaion of the numbers from 1 to 52 (or 0 to 51, depending on the current index origin). This can reasonably be called "shuffling cards" although to display this list of values as symbold for cards would take a little more code. This is 5 characters, but only 3 symbols, as i would call a single number a single symbol, no matter how many digits it needs to represent it. In fact, this function is called "deal" which makes the suggested use tolerably obvious. Of course all of these characters appear on a standard keyboard.

To represent dealing 52 cards to 4 players, one might write something like:

D {gets} 4 13 {reshape} 52 ? 52

That is 11 characters, two of which are non standard: {gets} which represents the left-pointing assignment arrow, and {reshape} which represents the shape/reshape primitave function, a version of the greek character rho in a standard AL character set.

Do you think this like of code, perhaps in an image foramt should appear in the article to clarify (and in part debunk) the quote? DES 18:09, 21 Feb 2005 (UTC)

Actually, I meant it as a joke. I am slightly bemused at how an off-hand remark I made in 1998 on Usenet found its way into Wikipedia (original post), but that's Usenet for you... David.given 19:19, 20 January 2007 (UTC)

[edit] Humourous Rhyme

Tis the dream of each programmer Before his life is done, To write three lines of APL And make the damn thing run.

I remember seeing this posted prominently in someone's office at Sharp Special Systems in Toronto in the early 1980s. The Special Systems guys were not APLers, but rather programmed in something like C or Fortran. Except that the dream was to write two lines of code, not three.

I never found this particularily funny, mostly because I always felt that APL was so incredibly easy. However, I feel that this rhyme is well placed and belongs here.

--Cowznofski 29 Nov 2006

[edit] Overview

The line used to read:

As APL has so many nonstandard primitives (functions, operators, or features built into the language and indicated by a single symbol or a combination of a few symbols),

APL has built-in functions and operators, and that's about it. As far as other symbols ("features built into the language and indicated by a single symbol"), they are few:

Branch Arrow - not a primitive really, but a bit of punctuation. More like a control structure.
Diamond - this is a statement separator. Not a function. No version of IBM APL had this until fairly recently.
Semicolon - used to separate a list of local variables in a function header or list of subscript expressions in old indexing.
Colon - used to indicate a line label.

I have changed this sentence accordingly.

--Cowznofski 10 Dec 2006

[edit] Examples

Why explain APL sentences from right to left? In practically all programming languages execution of the parsed text results in execution from right to left, complicated by the rules of precedence. I never saw anybody explaining a Fortran sentence from right to left, although that is precisely what happens during execution. If I remember well the "APL360 Primer" explicitly stated that APL statements should be read from left to right. The absence of function precedence makes interpretation quite simple: apply the function to everything that follows.

If we take the example $(\sim{}R\in R\circ.\times R)/R\leftarrow 1\downarrow\iota R$ , the comments don't tell us "what" the statement does but only "how" it does it. It certainly is not an illustration of the traditional definition of a prrime which is "only divisible by itself and by 1". Looking from left to right however we see that a selection is made of the elements within $R$ (BTW it is considered very bad APL programming practice to have a variable reassigned within the same statement, unless for sound reasons. <iota N> would have been cleaner than <iota R>). The selection part within parentheses tells us that "all elements of R are selected which are not present in" ( $\sim R\in$ ) "all the possible pairwise products of elements of R" ( $R\circ.\times R$ ). In other words a prime is defined as "an integer which cannot be represented as a product of two integers smaller or equal to itself and larger than 1". All one needs is knowledge of traditional mathematical and logical symbols, the APL representation of outer product and knowledge of the select operator. In fact only the select operator is new, all the rest can be considered as "public domain knowledge".
Starting from the traditional definition of primes and knowing that a divisor A of B is smaller or equal to B and leaves a rest of zero and that, for the natural numbers, the rest is the result of a modulo-division ( $0 = A\mid B$ ) the statement "select from R all elements where 2 equals the sum of all its divisors" (including 1) we get immediately $(2=+/[1]0=R\circ.\mid R)/R\leftarrow\iota N$ where $+ / [1]$ is read as "sum" (the [1] is a technicality since, in a matrix, sums can be made either along rows or along columns). When reading the statement from left to right the only difficulty is knowing that $0=R\circ.\mid R$ represents "all divisors".

For a beginner, the main difficulty in reading APL from left to right lies usually in the "." operator which defines a generalized inner and outer product and hence a plethora of idioms like $+.\ne$ in the sort example ("sum of all characters/numbers not equal to"). These idioms are sometimes difficult to formulate in normal speech and, more often than not, need complete subroutines in traditional (i.e. almost all) computer languages.

--Gvandor 19:29, 4 July 2006 (UTC)

On the one hand, this classic code fragment shows "APL's expressive power", but is also an interesting example of another, less publicized, and more insidious weakness of APL: Overcomputing. Granted the APL approach is to avoid iteration, here the problem is that a huge intermediate result is generated. Clearly, other algorithms exist, but without the theater. Brevity can be a two-edged sword.

As for innner products, i.e. +.=, ^.=, a more correct view for the beginner would be to view these compositions as functions in their own right, an idiomatic approach. Many interpreters even work this way. Operators take functions as arguments and produce derived functions. For purposes of learning, however, viewing +/ as a sum function is upwards-compatible with the operator - function - argument hierarchy.

--Cowznofski 24 Nov 2006

I think the new examples which recently (around 10 Feb 2006) appeared were very appropriate and quite suitable for inclusion. However, I think that in all fairness to the guy who might want to type the code fragments in and give them a try, the examples should be vendor-neutral wherever possible. Both examples could easily be expressed without the dynamic function {} and commute "~ operator, as a courtesy to the guy who wants to try the example on his colleague's APL2000 or APL2 system.

Cowznofski 08:43, 10 February 2007 (UTC)

[edit] Sort Example

I cannot see whether it is correct or not (since indeed APL is a write-only language) -- but at least: where is the SORT operator?? --217.245.7.251 12:39, 5 Feb 2005 (UTC)

The primiive functions grade up, and grade down ((“) and (”) view with an APL font) -- they are not operators in APL terminology -- sort arrays of numeric values. If the array is multi-dimensional, a multi-way sort will be performed. The result is the set of indicies needed to reshape the array into a sorted form. Sorting of character data is also provided by these functions, but a left arguemt giving the collating sequence to be used must be supplied. A complex sequence (for example, upper and loewr case letters rating as identical unless needed to break ties) can be provided by using a multi-dimensional left argument. DES 17:50, 21 Feb 2005 (UTC)

[edit] 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)

[edit] 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)

[edit] 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)

Expansion requests

, in Europe at least,

[edit] 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)

[edit] 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)

[edit] 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)

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.

[edit] 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.

[edit] 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

[edit] 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)

[edit] 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

[edit] 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)

[edit] 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)

[edit] Requested move

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

The following discussion is an archived debate of the proposal. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the debate was move as outlined. -- tariqabjotu 02:43, 7 September 2006 (UTC)

Note: This poll has been transcluded onto the talk pages of a number of individual programming languages, but is in fact a subpage of Wikipedia talk:WikiProject Programming languages. When you comment, please note that this survey is for multiple programming languages, not just the one you saw it on.

Some editors have proposed a general rename of articles named with the pattern "FOO programming language" to the pattern "FOO (programming language)". Please note that this poll only is applicable to those programming languages whose names alone would introduce ambiguity. For example, programming languages such as Java and C , whose names alone are ambiguous, would be at Java (programming language) and C (programming language), respectively. Unique names such as Fortran and COBOL, should remain at their respective simple names.

For instructions on how to add a poll participation request to additional applicable article talk pages, please see: Wikipedia talk:WikiProject Programming languages#Poll procedure

Please add "* Support" or "* Oppose" followed by an optional brief explanation, then sign your opinion with ~~~~

[edit] Voting

~~Abstain~~ Support - I initially abstained because I just wanted to get a procedure rolling. Looking at the first few comment, I support the rename. As with other editor, I only want this where ambiguity exists in the name: e.g. for "Python" but not for "Perl". Also, something like "Python programming language" would still redirect to "Python (programming language)" under the proposal, so existing links would not break. LotLE×talk 22:32, 1 September 2006 (UTC)
Support - However, I would object to specifying "programming language" anywhere in the title, as parenthetic remark or not, if the name of the language itself does not have any ambiguity issues. For example C programming language should change to C (programming language) (since C is already taken), but Fortran should stay at Fortran. --Serge 23:24, 1 September 2006 (UTC)
Support - originator of the request; it would also meet the common names policy and also meet the disambiguation guideline. atanamir 23:32, 1 September 2006 (UTC)
Oppose. The convention has been "<name of language> programming language" for quite a while and I don't think it helps by changing it now. There are already redirects in place for "<name> (programming language)" and it would only add more work to move them all there. Also, it goes against conventions in other media. In books related to programming on the copyright page where it sometimes has sorting information for the book many books say "Computers & Internet - <name> programming language I. Title" or something similar. - DNewhall 23:32, 1 September 2006 (UTC)
Oppose. To quote Wikipedia:Disambiguation, "When there is another word (such as Cheque instead of Check) or more complete name that is equally clear (such as Titan rocket), that should be used.". It is undeniable that the "C programming language" is a widely-understood name, not just a description. There's a reason K&R's book is called The C Programming Language rather than C, a Programming Language. Diverse examples from other areas include French language, Titan rocket, sticking plaster, bread roll, contract bridge. What makes programming languages different from these topics? Deco 23:44, 1 September 2006 (UTC)
- If those articles were named like the programming languages are currently, they would have been something like sticking plaster dressing, bread roll food, and contract bridge card game. Titan rocket, in fact, is a redirect to Titan (rocket family). The natural languages are a slightly odd exception to the normal convention, but i'm not a linguist, and not about to argue with them. (I do know, however, that many non-English Wikipedias use the normal (parenthesized) disambiguation convention for natural languages.) --Piet Delport 13:40, 2 September 2006 (UTC)
  - Apologies for the bad example - Titan rocket was moved since it turned out to be a rocket family, but others such as Angara rocket were not. The controlling question here is whether "C programming language" is a "more complete name" for C. I argue that it is, and so standing guidelines strongly support the current name. Deco 10:12, 3 September 2006 (UTC)
    - I would argue that isn't. You can say "I play contract bridge" and "I use C", but not "I use C programming language". You can expand the names into noun phrases, as in "I play the contract bridge card game" and "I use the C programming language", but in both cases "the * card game" and "the * programming language" are not part of the name itself, anymore. --Piet Delport 06:04, 4 September 2006 (UTC)
      - The presence or absence of a leading article is not a reliable indicator of whether it's a name or not, as indicated by French language, unless you wish to expand this proposal to move X language -> X (language) as well. Deco 06:28, 4 September 2006 (UTC)
        
        Definitely not something i'm interested in pursuing; let the linguists and editors involved with natural languages worry about their own naming convention. --Piet Delport 12:09, 4 September 2006 (UTC)
        
        (I know I am commenting on a now old post, but...) My take on "French language" is that it's different from "C programming language" since French is the language of the French. However, "C" is not a language named after a culture, country, or people (or anything). "C" only refers to C; "French" refers to a whole lot more than a language. Also, "French" is descriptive, but "C" is not. There's no need to clarify "C" or let it modify a noun. But being that a one letter name for something is inherently ambiguous, as well as names such as "Java" or "Python" (as already mentioned), there needs to be the parenthetical, "(programming language)".
Support - due to its name being "Ruby". --Yath 01:31, 2 September 2006 (UTC)
Support - this is the standard way that most Wikipedia articles are named. Use the common name and disambiguate appropriately using parentheses when necessary. --Polaron | Talk 01:43, 2 September 2006 (UTC)
Oppose - For the same reasons as DNewhall. Chris Burrows 02:11, 2 September 2006 (UTC)
Oppose — Per Deco, I don't see how adding parentheses to an article title which is already clear is an improvement. --Craig Stuntz 02:47, 2 September 2006 (UTC)
Support -- Crypotography has had much the same problem for some time. It has adopted the "<topic> (cryptography)" approach which has worked well. Not elegant perhaps, but ... ww 05:20, 2 September 2006 (UTC)
Oppose — Either way, there should be a second link so that both "C (programming language)" and "C programming langage" produce the C article. My main reason for opposing is that it isn't really consistent with the new "C programming language, criticism" page that was spun off the main C article; what would that name turn into? By the way, the official standard name is "programming language C", but to me that sounds too much like "PL/C" which would be wrong. Deco's remark is quite right. — DAGwyn 07:56, 2 September 2006 (UTC)
Comment. This proposal is different from the original proposal, found here, which is now understood as having unanimous consensus in favour. Please do not interfere with the original proposition by misrepresenting it and opening a straw poll here, which can only serve to undermine the usefulness of the original proposal. It would have been much better to simply post a link. - Samsara (talk • contribs) 09:40, 2 September 2006 (UTC)

The original proposal seems pretty wacko to me, and I don't see any evidence of a consensus. As I understand it, this current section is not a "straw poll", but a genuine attempt to determine whether or not to move the C article to a new name, independently of whether that wacko proposal is accepted. — DAGwyn 09:53, 2 September 2006 (UTC)

Oppose - As per Deco, if syntactically correct name is enough for disambiguation, it should be preferred. And also, without parentheses it's more pythonic (readability counts). Samohyl Jan 10:24, 2 September 2006 (UTC)
Strong Support — The current convention is at odds with the rest of Wikipedia, and as cumborsome as it would have been to have things like Quicksilver novel, Manowar band, and Darwin operating system. --Piet Delport 13:28, 2 September 2006 (UTC)
Support. Needs disambiguating, and the name seems to be to be currently misleading. --maru (talk) contribs 19:25, 2 September 2006 (UTC)

In what way is "C programming language" misleading? I can't think of a more natural title for such an article. — DAGwyn 05:48, 4 September 2006 (UTC)

Support. ~~Those opposing often~~ Some of those opposing assume that the poll is about deleting the "X programming languages" links - this is not correct. Nor is the intention to move names which are unambiguous, such as Fortran. Aaron McDaid (talk - contribs) 23:06, 2 September 2006 (UTC)
- For the record, I do not make either of these assumptions, and continue to oppose on the stated grounds. Deco 10:10, 3 September 2006 (UTC)
  - I didn't intend to imply that there weren't other reasons for opposing. Thanks for pointing that out Deco. Aaron McDaid (talk - contribs) 10:33, 3 September 2006 (UTC)
    - Don't worry about it - I appreciate your clarification that these are not valid grounds for opposition. Deco 10:38, 3 September 2006 (UTC)
Support per Piet Delport. -- Earle Martin 23:35, 2 September 2006 (UTC)
Support per Earle Martin. -- Fredrik Johansson 12:54, 3 September 2006 (UTC)
Support per Piet Delport. – Smyth\^talk 14:33, 3 September 2006 (UTC)
strong support. Piet Delport puts it well. Programming language articles should be disambiguated the same way that other Wikipedia articles are. — brighterorange (talk) 18:15, 4 September 2006 (UTC)
EMPHATIC Support I've wanted this to happen for a long time now. Per Piet Delport. RN 10:34, 5 September 2006 (UTC)

[edit] Discussion

[edit] Response to DNewhall's comment

In order to reduce clutter in the voting section, i've deicded to respond to DNewhall's vote here. If you're afraid of the amount of work it would take to move the articles, I can move most of them and i'm sure there are other editors willing to take up the task. Also, most books about programming languages simply have the title or common name of the programming language as the title of the book -- the Wrox series uses "Professional PHP" or "professional Java", not "professional PHP programming language" or "professional Java programming langauge". Many of the books I have also have the sorting information as "Computers -- Programming languages -- X," where X is the programming language. atanamir 23:36, 1 September 2006 (UTC)

The main issue is not that I'm afraid of the work but that it'll be a lot of work with next to no perceived benefit. Both "Euphoria programming language" and "Euphoria (programming language)" go to the same page and I (and others apparently) fail to see how that is an improvement over the current convention. The text is exactly the same, you're just adding parentheses. No one is going to get confused about the lack of parentheses (also remember that the names with parentheses already have redirects in place). Is "<name> (programming language)" a more correct title for the article? Arguably. Is it worth the effort of moving all the pages over from their perfectly understandable title to a title that already has a redirect in place for it? No. - DNewhall 16:10, 2 September 2006 (UTC)

I think you misunderstand the point of stylistic consistency on Wikipedia. Any one article in isolation would be fine under either convention; in fact, if the project was only the one article on, e.g. "C programming language" there would be no contrast with all the other uses of parens for disambiguation. But if WP (or some subset) was prepared for print or other syndication, having relatively consistent stylistic choices helps a lot (article naming is, of course, just one small issue among many others, of course). The work involved in a rename would, obviously, be a tiny fraction of the work involved in discussing the question, so that is "vanishingly insignificant". LotLE×talk 16:42, 2 September 2006 (UTC)

When it comes to C, we need to clear and distinct names for the articles on the programming language article and for the book. C (programming language) and The C Programming Language (book) are those two names. They are unambiguous and (or is that because?) they conform with the Wikipedia standard. Anything else should be a redirect to one or disambig page to both. 'C programming language' should redirect to the language and 'C Programming Language' to the book or a disambig page. The existence of a book called 'The C Programming Language' is actually an argument in Support. Aaron McDaid (talk - contribs) 12:49, 4 September 2006 (UTC)

... Appending to own comment ... It's never referred to directly as 'C programming language'. It's always 'C' or 'the C programming language. Note the ' the '. The latter is of the form 'the X Y' where X is the name and Y is the type of object. 'the X Y' (or even 'X Y') is not a new name for the object, simply a way to refer to X where there may be some ambiguity. Aaron McDaid (talk - contribs) 13:07, 4 September 2006 (UTC)

[edit] Repsonse to Deco's comment

Imagine if you have a set of objects which all fall under the same category -- let's say they're all different types of Widgets. The types are Alboo, Kabloo, Hello, Wawoob, Baboon, Choogoo, Chimpanzee, etc. Because some will cause ambiguity -- Hello, Baboon, and Chimpanzee -- they need to be disambiguated. However, since the common name (in this case, the real name) is "Hello," "Baboon," and "Chimpanzee," wikipedia has an established precedent of using parentheses. Thus, the unique widgets, Alboo, Kabloo, Wawoob, Coogoo, can have articles simply at the name itself; but the ambiguous names should have articles at Hello (widget), Baboon (widget), and Chimpanzee (widget). Thus, the article titles will be uniform in that they are all "at" the name itself, but with a disambiguator on several of them. This is easier than making all of the articles at Alboo widget, Kabloo widget, Hello widget, etc. Also, it allows for the pipe trick, so links can easily be made with [[Hello (widget)|]] --> Hello. atanamir 23:54, 1 September 2006 (UTC)

an example of this that's currently on wikipedia is colours. Some colours, such as Blue, Brown, and Red are at their articles, but colours like Orange (color) need the disambiguation part on them. It isn't at Orange color, althouh there is a redirect -- we can do the same thing with redirects. atanamir 23:57, 1 September 2006 (UTC)

also, your examples -- Titan rocket is a redirect for Titan (rocket family). Your other examples do not incite ambiguity, otherwise they'd be at places like Contract bridge (card game) atanamir 00:33, 2 September 2006 (UTC)

Titan rocket may now be a redirect, since it turned out to be a family of rockets rather than a single rocket, but there are still many rockets named that way (e.g. Angara rocket) and it's still cited on Wikipedia:Disambiguation specifically. The miniscule convenience of the pipe trick is not a reason for anything. My point is that this is a much wider concern than programming languages alone and represents a significant departure from the disambiguation guidelines. It would be radical to make such changes in a single area without raising them to the wider community, when your argument seems to apply to everything. The point of contract bridge and bread roll is that the more common names for these topics are "bridge" and "roll". Deco 07:48, 2 September 2006 (UTC)

[edit] Simpler disambiguation

Even if we add the parentheses, the guideline at Wikipedia:Disambiguation#Specific topic makes sense to me:

If there is a choice between disambiguating with a generic class or with a context, choose whichever is simpler. Use the same disambiguating phrase for other topics within the same context.

For example, "(mythology)" rather than "(mythological figure)".

In this case, we could have the simpler and more widely applicable "(computing)" instead of the long "(programming language)". --TuukkaH 10:04, 2 September 2006 (UTC)

I agree with the sentiment, but i think "(computing)" is too wide, with way too much opportunity for clashes:

Curl versus cURL
Curry versus Currying
Icon versus Icon (computing)
Leopard versus Leopard (DHT)
Mercury versus Mercury (computer)
Nice versus nice (Unix)
Pico versus Pico (text editor)
Ruby versus Ruby (hardware description language)

"(programming language)" might lean towards the long side, but i don't think any alternative class comes close to being as simultaneously large, well-defined and well-populated. --Piet Delport 15:14, 2 September 2006 (UTC)

I agree that if we were to use parentheses, "(computing)" is not specific enough. Your examples are excellent, particularly "Icon", which clashes with an already-existing article! Deco 10:40, 3 September 2006 (UTC)

Perhaps you're right in that it's not specific enough. On the other hand, the disambiguation can never be perfect as there are several programming languages that share a name: NPL has three programming languages, The Language List has four programming languages called G. What about "(language)" then? --TuukkaH 22:02, 3 September 2006 (UTC)

"Language" connotes something rather different from "programming language". "Lisp (language)" for example. "Programming language" is the accepted category in the industry, abbreviated to "PL" quite often in discussions (whereas "L" is never used for this). — DAGwyn 05:59, 4 September 2006 (UTC)

What about just "(programming)"? Or is that too ambiuguous as well? atanamir 02:39, 5 September 2006 (UTC)

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

[edit] Pages like C programming language, criticism

To meet the new standard, the pages should be moved to something like Criticism of C (programming language), right? examples are Georgia (U.S. State) and Politics of Georgia (U.S. state). atanamir 02:42, 5 September 2006 (UTC)

Depends on the page in question, most likely; some would work like above, some (like C syntax) wouldn't require any changes, and some might want to use a different method to disambiguate. --Piet Delport 05:55, 5 September 2006 (UTC)

Agreed with Piet; only the ones that would incite ambiguity -- simply "Criticism of C" would have ambiguity, but "C syntax" or "Syntax of C" are both rather unambiguous and would not need change. atanamir 06:01, 5 September 2006 (UTC)

Surely, criticism of C is pretty unique and should be the article? Are there any other C's that would be criticized? Aaron McDaid (talk - contribs) 21:41, 5 September 2006 (UTC)

I agree that the most likely "C" to be criticised is the programming language, but some may be looking for a criticism of the letter or magazine. Unlikely, but possible. This decision would be left up to the community, though. atanamir 01:57, 6 September 2006 (UTC)

As of now, there is only one C that is criticized on Wikipedia, and I am not aware of anyone wanting to write an article criticizing any other Cs. Therefore, criticism of C is unique. The Wikipedia standard is to only disambiguate when necessary. That article should be moved to criticism of C at some point, but we should let this debate finish first. Aaron McDaid (talk - contribs) 09:16, 6 September 2006 (UTC)

For the record, "Criticism of C" didn't even exist until I created the redirect yesterday. Was kind of surprised because it was at that wierd, longish name and is a pretty good article :). RN 10:19, 6 September 2006 (UTC)

The C criticism article was split off from the main C article, where it had previously been embedded, in response to a requirement in order for the main C article to be designated a "Good Article". I picked the name with the idea that it was a sub-article of the main one. Once the discussion has settled, I don't object to some reasonable renaming, so long as the links between the two articles are fixed up so they still point to each other. — DAGwyn 21:51, 6 September 2006 (UTC)

Aaargh! Whoever just renamed the main C article ignored this linking issue. I have edited the C criticism article so its link to the C article does not have to redirect. — DAGwyn 20:20, 7 September 2006 (UTC)

The term "criticism" should not be used (I've stated reasons for this on Talk:C (programming language); the more accurate term of "analysis" or something similar should be used. Dysprosia 03:54, 7 September 2006 (UTC)

You also received feedback to the effect that criticism doesn't have to be negative, that the article is fairly balanced, and that a list of limitations has to seem somewhat negative no matter how well-intentioned it may be. The C criticisms article is not at all a complete analysis of the language, just a description of the many characteristics of C that have drawn reasonable criticism. Since C is so popular and wide-spread, it is a target for a lot of sniping and second-guessing, and it is undeniable that that has happened, which is part of what the C criticism article specifically addresses. One of the useful functions of the C criticism page is to bring some balance to that criticism. — DAGwyn 20:20, 7 September 2006 (UTC)

I also responded to that comment by saying (and I'll repeat the comment here for the benefit of readers of this page) that the term "criticism" still has primarily a negative connotation and that because of this it is an undesirable term. The article in question has the potential to contain discussion on design points on the language and opinions on those who comment on these design points. That is an analysis of the design of the language, and has the potential to encompass views from all points on the spectrum on the matter. Dysprosia 07:43, 8 September 2006 (UTC)

I just want to chip in that i agree with DAGwyn that "criticism" does not carry negative any primarily negative connotations in this context. As the criticism article says:

"In literary and academic contexts, the term most frequently refers to literary criticism, art criticism, or other such fields, and to scholars' attempts to understand the aesthetic object in depth."

There are certain fields ("In politics, for instance [...]") where "criticism" connotes mainly negative criticism, but it should be reasonably clear that encyclopedias won't limit themselves to that. --Piet Delport 23:32, 10 September 2006 (UTC)

Technically, it shouldn't carry any as you suggest but most seem to think it is a dumping ground for it. I would recommend "Analysis" as that's what I'm doing for criticism page I watch. RN 23:43, 10 September 2006 (UTC)

"Analysis" usually implies something more formal, complete and reductionistic, though. Is that what the article is aiming for? --Piet Delport 00:00, 11 September 2006 (UTC)

It doesn't need to imply that. The article in question however should aim to examine as many viewpoints on as many language points as possible. Dysprosia 02:33, 11 September 2006 (UTC)

Unfortunately, the C (programming language) article itself does force the negative connotation on the reader by saying "Despite its popularity, C has been widely criticized. Such criticisms fall into two broad classes: desirable operations that are too hard to achieve using unadorned C, and undesirable operations that are too easy to accidentally achieve while using C. Putting this another way, the safe, effective use of C requires more programmer skill, experience, effort, and attention to detail than is required for some other programming languages." That whole paragraph implies that the article Criticism of the C programming language is negative (why else say "Despite its popularity" and then cite two negative classes?) Mickraus 17:14, 24 January 2007 (UTC)

[edit] 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.

Retrieved from "http://en.wikipedia.org../../../a/p/l/Talk%7EAPL_%28programming_language%29_806b.html"