We have inherited a bunch of "J" code at work (J is the ascii successor to APL). While I can see the esoteric appeal, I think J/APL is at best a concept language, useful for exploring a syntactical idea. The email list is full of hobbyists going on about how they shaved three characters off of a ten character program that calculates every other prime number... or whatever. The other favorite topic is why APL is "mathematical" notation for computers, even though you can't use it derive new theorems or simplify exposition.
If you ask me, APL was great in its day (1965-1985) because it was the only language that natively handled vectors and matrixes, but once Matlab and S came on the scene it immediately became an evolutionary dead-end.
"Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do."
That's a nice sentiment, but it doesn't really fit the case at hand. The multi-thousand line explanation is only necessary for people who don't know APL. Once you are fluent in the language, a one-liner like the one shown requires very little explanation-- consider it the APL equivalent of the Ruby/Rails "blog in 10 minutes" demo (especially if you avail yourself of the 7 minute video I linked to elsewhere in this discussion.)
Each glyph in APL represents a conceptual construct, so the language is quite expressive of programmer intent--much moreso than many other languages I've used.
Its similar to the conciseness of Chinese vs. Romance languages. Chinese is great if I know Chinese, but which would you rather learn from scratch - Chinese or English? For human communication languages, it's generally agreed upon that languages with countless glyphs are more difficult to learn than languages with an alphabet.
Given an equation that relates given values a, b and c (which we shall hereby refer to as the "equation constants") and unknown variable x ("the unknown"), one solution to x that satisfies said equation is given by: taking the square root (which is the inverse of the square operation) on 4 times a times c subtracted from b squared, subtracting b from this result, and dividing all of this by 2 and then by a again.
Oh my. If mathematicians really thought that way, we would still not have discovered transcendental numbers.
APL is a mathematical notion for expressing algorithms. It does that quite well - as well, or better, than standard mathematical notation does for equations.
Have you ever met someone working in math or physics who would prefer english text to equations?
And yet you left out one of the solutions to that equation.
It's not always helpful to increase the density of information. In general, you only want to do that once you have everything worked out. We rarely have everything worked out in programming. But it's great to simplify the proofs and equations once we've worked things out in mathematics.
> And yet you left out one of the solutions to that equation. It's not always helpful to increase the density of information.
This mistake (forgotten second solution) demonstrates quite the opposite: It is very visible in the compact version, but would be almost hidden in the full-blown text.
(Note that the text is in fact correct because it differs slightly from the formula. Nevertheless, if the text had the same mistake, it wouldn't be nearly as obvious as in the formula.)
> Note that the text is in fact correct because it differs slightly from the formula.
Afraid not. When it said "taking the square root (which is the inverse of the square operation)", it was incorrect for implying that the square operation has a single inverse.
> And yet you left out one of the solutions to that equation.
Well, I left it out because I didn't have the +/- sign on the keyboard, and I didn't want to repeat the whole thing twice.
> It's not always helpful to increase the density of information. In general, you only want to do that once you have everything worked out.
I agree with this (and the original post), but not with the grandparent. In general I prefer a dense statement readable to someone "skilled in the art", with a textual description for those who don't.
However, most programming lore equates the "full description" with a "good solution", leaving the mathematical conciseness an impossibility with few exceptions; notable exceptions are the APL (A+, J, K, Q) family.
From "a*x^2+b*x+c = 0" follows "x1 = (-b + sqrt(b^2-4*a*c))/2*a"
indicating that the second part is the only solution.
Strictly speaken, since no equivalence has been used, this even means that there is either no solution, or if there is a solution, it must have the form "x1 = (-b + sqrt(b^2-4ac))/2*a".
However, I'm willing to admit that this is nitpicking.
> indicating that the second part is the only solution.
I'm not familiar with a notation in which implication means "only". As in:
x = 4 -> x > 3
does not in any way imply that x is the only number larger than 3, or that x is only larger than 3. I specifically wrote "x1" to indicate _a_ solution, not _the_ solution; if it was _the_ solution, there would have been no need for the "1" index.
> it must have the form "x1 = (-b + sqrt(b^2-4ac))/2*a".
Alternatively, since sqrt could be the multi valued function with no specific branch selected, this actually does give all the solutions.
> However, I'm willing to admit that this is nitpicking.
And I can't even find any appreciation for it - Because you picked a set of assumptions (x is Real or Complex, sqrt is a specific branch of a multi-branch function, no natural order for solutions) treated as axioms, but question others, where said axioms actually determine correctness.
Are you sure I was not, in fact, describing an equation in Z_2?
Nitpicking at this level, especially if you do it often, might make you feel good about yourself, but doesn't actually get you anywhere.
-- beagle3, who started professional life as a mathematician and switched to engineering at a later stage.
I'm afraid this is a misunderstanding. What I was trying to say is that if the right-hand side of an implication denotes a single solution, there can't be any other solution.
For instance, if you write something like this:
x^2 = 4 -> x = 2
this means that all solutions to "x^2 = 4" must satisfy "x = 2", which means that there can't be more than one solution. Any other solution than "2" would be a counter-example to this implication.
And since there is another solution, namely "x = -2", the implication above is wrong. In other words, from "x^2 = 4" is does not necessarily follow that "x = 2".
However, I agree that writing "x1" instead of "x" (as you did) kind of solves this notational issue.
> Alternatively, since sqrt could be the multi valued function with no specific branch selected, this actually does give all the solutions. [...] Are you sure I was not, in fact, describing an equation in Z_2?
Of course, nitpicking never stops.
If sqrt() was meant to be a multi-values function, why did the formula denote "x1"? Also, was "^" ment to be "power" or "bitwise XOR"? Is "sqrt" a product of four variables? And so on.
That is the whole point about admitting "nitpicking": We agree in how the formula is to be interpreted, so there is no need to get deep into formalities, as long as the real issues behind the whole stuff are clear (which they pretty much are).
> Nitpicking at this level, especially if you do it often, might make you feel good about yourself, but doesn't actually get you anywhere.
Correct me if I'm wrong, but this seems to be a mere ad hominem, not an actual argument. It is also a straw man, because I never claimed that this kind of nitpicking leads to somewhere. In my previous comment I was even implying quite the opposite.
> Correct me if I'm wrong, but this seems to be a mere ad hominem, not an actual argument. It is also a straw man, because I never claimed that this kind of nitpicking leads to somewhere. In my previous comment I was even implying quite the opposite.
You are wrong, but I will not correct you, as my sarcasm detector beeps strongly here. Correct me if I'm wrong.
If you ask me, APL was great in its day (1965-1985) because it was the only language that natively handled vectors and matrixes, but once Matlab and S came on the scene it immediately became an evolutionary dead-end.
Yuck.