Why APL is a language worth knowing
-
My problem with APL is that it encourages writing obfuscated code.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
My problem with APL is that it encourages writing obfuscated code.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Look up just about any (non-trivial) mathematical proof, and it is "obfuscated" in the same manner: A lot of strange symbols that - to most non-mathematicians - make no sense whatsoever. APL wasn't developed as a programming language, but as a notation for blackboard teaching of advanced math topics. The math students had to learn the meaning of a few extra symbols, in addition to the plethora of symbols they already knew. Most APL critics would consider the language to be less obfuscated if you simply replaced the special APL characters with word symbols (such as 'reshape', 'execute', 'invert', ...). Yet, when reading math, they can easily handle sigma, integration sign, delta, root sign, pi, e and i symbols, without complaining about 'obfuscation'. If you learn the symbols of APL, the language still has elements that differ from the 'Algol type' languages. (Today, few people ever saw an Algol program, so let us call it 'C type' :-)). E.g. no operator priorities. Functions and values exist in a 'workspace', with no defined 'ordering' as a source file. Many (most) operators work on an entire matrix of arbitrary dimension, rather than iterating over the elements. These are examples of different approaches to programming, but they can hardly be called 'obfuscation'. If you say that they are, then any significant deviation from 'c style' could be called 'obfuscation'. Lots of people have no need for learning calculus, so they don't need to know integration and sigma and delta and root symbols. We should accept that. We should also accept that many (probably the great majority of) programmers have no need to learn the symbolism for expressing matrix operations in a programming language made for that kind of problems. We should accept that as well. If a non-mathematician looks at a differential equation and calls it 'obfuscated', mathematicians would probably just reply with a forgiving smile. If a non-APLer looks at an APL program and calls it 'obfuscated', the APL programmer would reply similarly.
-
No votes here I'm afraid: Slant~programming-languages-for-data-science[^] :-\
-
Look up just about any (non-trivial) mathematical proof, and it is "obfuscated" in the same manner: A lot of strange symbols that - to most non-mathematicians - make no sense whatsoever. APL wasn't developed as a programming language, but as a notation for blackboard teaching of advanced math topics. The math students had to learn the meaning of a few extra symbols, in addition to the plethora of symbols they already knew. Most APL critics would consider the language to be less obfuscated if you simply replaced the special APL characters with word symbols (such as 'reshape', 'execute', 'invert', ...). Yet, when reading math, they can easily handle sigma, integration sign, delta, root sign, pi, e and i symbols, without complaining about 'obfuscation'. If you learn the symbols of APL, the language still has elements that differ from the 'Algol type' languages. (Today, few people ever saw an Algol program, so let us call it 'C type' :-)). E.g. no operator priorities. Functions and values exist in a 'workspace', with no defined 'ordering' as a source file. Many (most) operators work on an entire matrix of arbitrary dimension, rather than iterating over the elements. These are examples of different approaches to programming, but they can hardly be called 'obfuscation'. If you say that they are, then any significant deviation from 'c style' could be called 'obfuscation'. Lots of people have no need for learning calculus, so they don't need to know integration and sigma and delta and root symbols. We should accept that. We should also accept that many (probably the great majority of) programmers have no need to learn the symbolism for expressing matrix operations in a programming language made for that kind of problems. We should accept that as well. If a non-mathematician looks at a differential equation and calls it 'obfuscated', mathematicians would probably just reply with a forgiving smile. If a non-APLer looks at an APL program and calls it 'obfuscated', the APL programmer would reply similarly.
trønderen wrote:
Yet, when reading math, they can easily handle sigma, integration sign, delta, root sign, pi, e and i symbols, without complaining about 'obfuscation'.
You're speaking European school system.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
Look up just about any (non-trivial) mathematical proof, and it is "obfuscated" in the same manner: A lot of strange symbols that - to most non-mathematicians - make no sense whatsoever. APL wasn't developed as a programming language, but as a notation for blackboard teaching of advanced math topics. The math students had to learn the meaning of a few extra symbols, in addition to the plethora of symbols they already knew. Most APL critics would consider the language to be less obfuscated if you simply replaced the special APL characters with word symbols (such as 'reshape', 'execute', 'invert', ...). Yet, when reading math, they can easily handle sigma, integration sign, delta, root sign, pi, e and i symbols, without complaining about 'obfuscation'. If you learn the symbols of APL, the language still has elements that differ from the 'Algol type' languages. (Today, few people ever saw an Algol program, so let us call it 'C type' :-)). E.g. no operator priorities. Functions and values exist in a 'workspace', with no defined 'ordering' as a source file. Many (most) operators work on an entire matrix of arbitrary dimension, rather than iterating over the elements. These are examples of different approaches to programming, but they can hardly be called 'obfuscation'. If you say that they are, then any significant deviation from 'c style' could be called 'obfuscation'. Lots of people have no need for learning calculus, so they don't need to know integration and sigma and delta and root symbols. We should accept that. We should also accept that many (probably the great majority of) programmers have no need to learn the symbolism for expressing matrix operations in a programming language made for that kind of problems. We should accept that as well. If a non-mathematician looks at a differential equation and calls it 'obfuscated', mathematicians would probably just reply with a forgiving smile. If a non-APLer looks at an APL program and calls it 'obfuscated', the APL programmer would reply similarly.
I must disagree. APL lends itself to writing one-line programs that perform highly complex operations. This is both its greatest strength and its greatest weakness, because maintenance of such code is next to impossible. It is, of course, equally possible to write obfuscated C code (see the Obfuscated C Contest), but one has to work harder at it. The comparison to a mathematical proof is inappropriate. Mathematical proofs may be highly complex, but they rarely require maintenance as in "oh, can you just add this one feature?"
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
I must disagree. APL lends itself to writing one-line programs that perform highly complex operations. This is both its greatest strength and its greatest weakness, because maintenance of such code is next to impossible. It is, of course, equally possible to write obfuscated C code (see the Obfuscated C Contest), but one has to work harder at it. The comparison to a mathematical proof is inappropriate. Mathematical proofs may be highly complex, but they rarely require maintenance as in "oh, can you just add this one feature?"
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
You missed the base point of APL - it was developed to assist with mathematical proofs. The language closely follows the syntax of abstract mathematics, which is extremely powerful and also extremely obscure to non-mathematicians. Also, once you learn APL using a true APL keyboard it turns out to be a relatively easy language to understand.
-
No votes here I'm afraid: Slant~programming-languages-for-data-science[^] :-\
-
I'm not sure how he intended his article to demonstrate that APL changed his way of thinking about programming, as what he writes about is all common stuff in most languages nowadays. Certainly when APL was created, this was probably revolutionary, but not nowadays.
Latest Article:
Create a Digital Ocean Droplet for .NET Core Web API with a real SSL Certificate on a Domain -
I'm not sure how he intended his article to demonstrate that APL changed his way of thinking about programming, as what he writes about is all common stuff in most languages nowadays. Certainly when APL was created, this was probably revolutionary, but not nowadays.
Latest Article:
Create a Digital Ocean Droplet for .NET Core Web API with a real SSL Certificate on a DomainMy immediate reaction to the article was: That is most certainly true! When I learned APL, it quite significantly changed my way of thinking about programming, too. If know little more about APL than it uses a strange character set and a solution can be written in one line, then there is no way you will understand how it really can change your thinking. You have to learn it, not just the meaning of the symbols, but the entire programming model. APL is not the only language forcing you to think differently. Lisp is another one. And Prolog - it has some relatives, such as regex or Snobol4, or xslt, but doing the entire problem solution in predicate logic is most certainly different from defining a regex for analyzing a string! I think it is a pity that the only way most programmers can think of programming is the sequential from-begin-to-end C style. The original MacOS and Windows tried to introduce event driven models, but both essentially had to give it up. The only essential change we have had since Fortran II to our way of thinking about programming is not even a change, only an extension: We now solve problems by splitting it into several parallel processes/threads. But each of them might be programmed in Fortran II, at least conceptually. I don't know of any widespread language that has thread concepts as first class citizen; the very most is realized as add-ons: Libraries with classes and methods. I also think it is a pity that we know at most two operating systems, *nix and Windows - and seen from a distance, they are so similar that I am a little hesitant to refer to them as 'two'. Every now and then, I get nostalgic and dig up some of my old books, typically from the early 1980s, to recall all the great ideas that once were thriving, in language design, OS design and machine architecture. Repeatedly, I ask myself: Why did we abandon all those ideas? Some of them were great! Not all, but some of them could most certainly be revived and tried anew.
-
In the early 80s I designed an IBM OEMI Channel to Channel adapter using APL as a register transfer modeling and simulation language. A program written by my boss called SynAPL parsed the APL and synthesized the gates and registers. And the rest of our synthesis system partitioned the chips and produced the metallization masks for sea of gates Gate Arrays. The chips worked first time, no turns.