This is one area where Haskell really shines. If you want the machine to be able to do what you want without micromanaging how, than you need a way to formally specify what you mean in an unambiguous and verifiable way. Yet it also needs to be flexible enough to cross domain boundaries (pure code, IO, DSLs, etc).
Category theory has been doing exactly that in the math world for decades, and taking advantage of that in the programming world seems like a clear way forward.
The current state of the industry seems like team of medieval masons (programmers) struggling to build a cathedral with no knowledge of physics beyond anecdotes that have been passed down the generations (design patterns), while a crowd of peasants watch from all angles to see if the whole thing will fall down (unit tests).
Sure, you might be able to build something that way, but it's not exactly science, is it?
Gimme a break.
A better analogy would be being mad that the Tesla can't drive on the interstate.
Don't confuse local maxima for maxima. We need people exploring other slopes for the chance of an apex, or at least some higher local maxima.
It's mostly good for being able to express mathematical formulas with very little translation from the math world - "executable proofs," I think the quote is - and having matrices of arbitrary dimension as first-class values is unusual if not unique. But for any practical purpose it's to Haskell what Haskell is to Java.
Can you elaborate on this? As I understand, the core strengths of APL are succinct notation, built-in verbs which operate on vectors/matrices, and a requirement to program in a point-free style. All of this can be done in Haskell.
A Haskell programmer unfamiliar with APL looks at an APL program and...
Of course, understanding the individual symbols is a different matter, but hardly requiring a conceptual leap.
And says "what's the big deal?". That's exactly the question, what is the big deal. APL isn't scary, I'm not shouting "I can't make sense of this", I am asking "how is this better than haskell in the same way haskell is better than java?".
Your question is fine, but not what he meant by the analogy.
Not that I dislike the idea -- on the contrary, I'm inclined to conclude from my excitement over this and Haskell that I dislike success...
On a related note, if one plans to sell the Language of The Future Of Programming, I swear this thing will know the same fate as Planner, NLS, Sketchpad, Prolog, Smalltalk and whatnot if it cannot help me with the problems I have to solve just tomorrow.
Now, I didn't learn APL from a tutorial, I learned it (in 1976) from a book. This book: http://www.jsoftware.com/papers/APL.htm from 1962.
If my memory hasn't been completely corrupted by background radiation, I've seen papers as early as the mid 1950s about this notation.
APL started out as a notation for expressing computation (this is not precise but good enough). As far as I'm concerned it's sitting at a level of abstraction higher than Haskell (arguably like a library overtop Haskell).
Now, in the theme of this thread, APL was able to achieve all of this given the constraints at the time.
The MCM/70 was a microprocessor based laptop computer that shipped in 1974 (demonstrated in 1972, some prototypes delivered to customers in 1973) and ran APL using an 80 kHz (that kilo) 8008 (with a whole 8 bytes of stack) with 2 kBytes (that's kilo) RAM or maxed out at 8 kB (again, that's kilo) of RAM. This is a small slow machine that still ran APL (and nothing else). IEEE Annals of Computer History has this computer as the earliest commercial, non-kit personal computer (IEEE Annals of the History of Computing, 2003: pg. 62-75). And, I say again, it ran APL exclusively.
Control Data dominated the super computer market in the 70s. The CDC 7600 (designed by Cray himself, 36.4 MHz with 65 kWord (a word was some multiple of 12 bits, probably 60 bits but I'm fuzzy on that) and about 36 MFLOPS according to wikipedia) was normally programmed in FORTRAN. In fact, this would be a classic machine to run FORTRAN. However, the APL implementation available was often able to outperform it, almost always when coded by an engineer (and I mean like civil, mechanical, industrial, etc engineer, not a software engineer) rather than someone specialising in writing fast software.
I wish everyone would think about what these people accomplished given those constraints. And think about this world and think again about Bret Victor's talk.
Were those destroyed tutorials published books?
EDIT: I just opened the drop down on the paper covered versions. Prices between $34.13 and $1806.23!!! Is that real?!? Wow, I had five or six copies of something that seems to be incredibly valuable. Too late for an insurance claim on that basement flood.
Programming in APL, for me at least, was like entering into a secondary zone after you were in the zone. The first step is to be in the "I am now focused on programming" zone. Then there's the "I am now in my problem space" zone. This is exactly how it works with APL.
I used the language extensively for probably a decade and nothing has ever approached it in this regard. Instead we are mired in the innards of the machine, micromanaging absolutely everything with incredible verbosity and granularity.
I really feel that for programming/computing to really evolve to another level we need to start loosing some of the links to the ancient world of programming. There's little difference between what you had to do with a Fortran program and what you do with some of the modern languages in common use. That's not he kind of progress that is going to make a dent.