| The language is interesting, but the management ideas in this are very strange. Example: tin flippers. Items are being checked manually and miscounted. The numbers are inherently inaccurate. And he makes the point that this applies in many other situations - some where the inputs are mechanical, so "Use a machine" isn't a solution. ("Use a better machine" might be. But how would you know without being able to monitor output quality?) How is a programming language supposed to fix any of this? Finding gross inconsistenicies shouldn't be too hard, but automating broken processes algorithmically means you have automated broken processes. This is not at all the same problem as formally specifying software in ways that make it more reliable. The other problem is that it sees software as strictly sequential in->stuff happens->out. This is basically batch mode, not real time. As soon as you need real time I/O everything gets a lot more complicated. I don't see anything in APL that solves that. And that's even more true of business processes. To add: it's not that analytics can't be useful. But APL won't somehow magically guarantee that your analytics are any better or more useful than output from some other language or system. |
For the APL family, that's often a call for code which works with external interfaces. In many potential APL environments a handful of well designed custom primitives would get you where you need to go.
But no programming language is adequate for all roles, and that includes APL. (It can still be useful for modeling / prototyping for real time work, but that's not always necessary.)