5 ms·
Neat little tribute article. APL will not be reborn. If that was going to happen, this century's embrace of analytics and linear-algebra-rich machine learning
by untangle 8y ago
Neat little tribute article.
APL will not be reborn. If that was going to happen, this century's embrace of analytics and linear-algebra-rich machine learning would have propelled the upswell. It didn't and it won't.
Why? It's not the symbols. Not the keyboard. Nor the learning curve. Nor the lack of standardization, libraries, or GPU support. These are collateral damage, not primary drivers.
APL will not flourish because it is effectively a DSL with archaic I/O capability. It is a nearly-pure functional programming language. It's primary domain is mathematics. Native GUIs, networking, the web -- all uncompetitive add-ons.
In this sense, APL and Haskell share some DNA.
For dynamic systems modeling for my thesis, I reached for APL and Matlab. I still code Dyalog APL for recreation. Love it. But I wouldn't build a web app with it and a wouldn't run my company on it.
- derefr 8y agoIs there a reason one wouldn’t just build the core engine of SIMD math software in APL, much like people build the core engines of medical-system software in Prolog?
- todd8 8y agoIs Prolog really used for medical-system software? It seems to me that it turned out to be the wrong path taken by Japan's Fifth Generation Project. In the early 80's I experimented with Prolog. Simple ideas were simply coded into programs; it was really very interesting. However, the need to understand the compiler's inner workings to get programs that ran efficiently by manually inserting "cuts" to limit backtracking ruins Prolog's claim to being simple to translate requirements into programs. An even more serious problem with Prolog is the simplicity of it's model for logic. It is very easy to end up with requirements in the real world that don't easily fit the model. See for example the SHOOT problem in [1], where the concluding sentence is: > As such, the claim implicit in the development of nonmonotonic logics--that a simple extension to classical logic would result in the power to express an important class of human nondeductive reasoning--is certainly called into question by our result. Don't get me wrong, I was the Chief Scientist at a company with one Prolog based product. I still thinks its an interesting language, but I predict that it will remain eclipsed by much more general purpose programming languages. [1] https://www.aaai.org/Papers/AAAI/1986/AAAI86-054.pdf https://www.aaai.org/Papers/AAAI/1986/AAAI86-054.pdf
- blobjectivism 8y agoThe popular narratives that 5th generation computing, expert systems, etc failed to deliver because it was the 'wrong path' to take is bs, basically the hardware designers weren't used to non-turing architectures, it was hard to find (and hire) programmers that fully understood both non-imperative paradigms and hardware integration, and government funded science (outside of black budget defense and intelligence projects) education and research started taking a nosedive during the 80s.
- derefr 8y agoIt is! You don't use it for diagnosis; you use it to formalize treatment guidelines (which are effectively 'expert systems' even on paper.) It runs alongside more ML-based models, glued together under business-logic written in something like Java.
- YeGoblynQueenne 8y agoYou have got to give more details about this :)
- YeGoblynQueenne 8y ago>> In the early 80's I experimented with Prolog. Simple ideas were simply coded into programs; it was really very interesting. However, the need to understand the compiler's inner workings to get programs that ran efficiently by manually inserting "cuts" to limit backtracking ruins Prolog's claim to being simple to translate requirements into programs. Where does this claim come from? Prolog is an automated theorem prover for first-order logic theories. There have certainly been various arguments about the pros and cons of it made by many different people (not all of whom were close to the development of the language), but the fact remains that its main characteristic is the automation of a proof process. You can certainly find many flaws in Prolog if you look hard enough and choose your requirements carefully (for example- it has no functions! Why has it no functions? It should have functions! Therefore, it sucks). I think a lot of the bad rep Prolog's got over the years is the result of promises by various sources that had nothing to do with its actual goal, which was to create a language with the syntax and semantics of FOL- which it achieves not perfectly, but way, way better than anything else out there. >> I still thinks its an interesting language, but I predict that it will remain eclipsed by much more general purpose programming languages. That's probably true, though :)
- gaius 8y agoMorgan Stanley used APL successfully in their bond trading business for many years... its by no means an insurmountable hurdle. Last I heard they were using Java tho’, lol. From one end of the verbosity spectrum to the other!
- deleted 8y ago[deleted]
- bwanab 8y agoMS used APlus (http://www.aplusdev.org/index.html http://www.aplusdev.org/index.html) a derivative of APL. I was there during the transition and a common attitude in the Fixed Income group was "You'll pry APlus out of my cold dead keyboard".
- enord 8y agoI like your take, and Haskell is an apt comparison in this sense. Another sense in which i think APL is... un-competitive is that its strengths (terse, mathematical, matrix-centered) are the easy parts of programming, i.e. the parts that are the most objectively quantifiable and verifiable (you just use math). Accounting for numbers is trivial, accounting for human factors is a proverb.
- repsilat 8y agoI agree that Haskell is a good comparison. I think matrices and math are too closely focused on in array languages (and dismissals of array languages), though. For fun I'm writing a "spreadsheet programming language" that borrows a little from array languages, and I think there's useful stuff to take away from them. They make you focus on the data, and the transformations you want to effect on the data. They make you think, "where there's one, there's probably many." The implicit mapping over arrays for most functions and operators is a massive ergonomic win over "a formula for each row" in the spreadsheet model. (Excel "array formulas" but not shit.) Some of the simple little abstractions are beautiful. Seriously, as someone who didn't know anything about array languages three weeks ago, I say go spend a day reading the first two parts of the J book (http://www.jsoftware.com/help/learning/contents.htm http://www.jsoftware.com/help/learning/contents.htm) up to "Rank". It's this humble little operator that makes the whole language sing and fit together masterfully, and I'm heartbroken my language's data model (and programming style) isn't a good fit for it. Really, though, for me being able to have my (still hypothetical) non-programmer users type organisations[users.orgId] instead of users.map(({ orgId }) => organisations[orgId]) is a no-brainer. Ditto just about any place I might want to use an anonymous function in JS, really: sort(people, by: people.age) vs sort(people, ({ age }) => age) So simple. Pass an array of things to use as the sort key, not "a function to call on each item-to-sort". Forget the cryptic syntax, "operator ambivalence" and math/matrix-focus, there's a lot of useful stuff in there that should be better known in language circles. As for the grandparent's complaint of being "nearly-pure functional", that's the zeitgeist now -- functional transformation of data, with big ugly explicit data-replacement as the mutation story. That's not an impediment to use, it's an encouragement to use responsibly while not being too much of an encumbrance if you want to walk off the beaten track.
- keithalewis 8y agoIt will not become popular for one simple reason: you have to be smart to understand it. Want to be popular? Write a python^Wlanguage for people who shouldn't even be programming in the first place.
- sharpercoder 8y agoIf you think about it, a decent stack is composed of languages. That's currently already often true, e.g. the use of IDL languages like protobuf/flatbuffers. Some languages offer integrated idl like Kotlin (data classes). Another example is html, where the UI is described using a dsl to specify elements and CSS for layout & appearance. This fact caused me to think: should stack also not be made of other languages? Is there a place for a completely pure functional language? I mean, Haskell is nice, but get a bit awkward with I/O. Same for APL. C# has nicely integrated data querying, but from a distance is actually at least somewhat awkward. C# seems to be optimized for mutable domain objects; everything else can be nicely done but falls somewhat outside it's "identity". I would love to be able to express functions, functors and math using a terse math-y language. Whether that be APL or some sort of blend of Haskell and APL (Haspell? spelling pun intended), I don't care, but it would be great if we can have nice integrations of these languages in a full stack. Sort-of like how TypeScript and JavaScript have dialects to enable React syntax to express HTML within it. The same thought experiment can be applied to SQL. Can we have a data-querying language integrated right into, say, C# or Java?
- opnitro 8y agoThe language Racket (https://racket-lang.org https://racket-lang.org) sort of approaches this. It allows you to quickly switch which compiler a given source file is actually sent into, the goal being that you solve each problem with sub-languages particularly suited to the task at hand. For instance, the webserver language has HTML build in as a primitive.
- mattnewport 8y agoC# kinda does have a data querying language built right in with LINQ query expressions, although they seem to have rather fallen out of favor.
- rjbwork 8y agoIndeed. But you can still write functional style data querying languages using LINQ extension methods. IMO, LINQ based DB querying is revolutionary in terms of the flexibility and capabilities it provides. For complex Relational DB querying it's pretty great. I tend to write raw SQL using Dapper these days, because hey, scalability and such, but for business apps and non-cloud apps, EF and other LINQ-based DB tools are great.
- adw 8y agoAPL has flourished, as a DSL embedded in a language with excellent I/O. It's just got weird syntax and is called Numpy. Or Tensorflow. Or PyTorch...